Thank you so much Marco, now i understand :)
At 2014-08-23 04:46:57, "Marco Bungart" <m.bung...@gmx.net> wrote:
>Hi,
>
>execution-order is here the problem. Let me label some points in the
>sourcecode.
>
>public class Hello {
> public static def main(args:Rail[String]) {
> at(Place(1)) async test(); // Point 1
> while(true) { Runtime.probe() }// Point 2
> }
>
> public static def test() {
> at(Place(0)) async { // Point 3
> val a = 1+2; // nerer be called
> Console.OUT.println("a:"+a);
> Console.OUT.flush();
> }
> }
>}
>
>First, you should know, that an activity blocks a core, as long as it is
>not finished. X10 will not automatically "swap out" an activity, which
>is waiting or in an endless loop.
>
>Next, there is an essential difference between "at (...) async" and
>"async at (...)". If you have had used async "at (...)", Point 1 would
>have never been executed. Reason: "async" starts a new acitivity at
>Place(0) (since there is no "at" in front of it). But this place is busy
>executing the current activity (main-method) and is queued. So, Place(0)
>executes Points 2, will never finish and therefore never execute the
>queued activity (aka. Point 1).
>
>Now to the actual problem. Place(0) starts by executing Point(1). Since
>there is no activity running at Place(1), it starts executing "test()".
>Meanwhile, Place(0) executes the endless-loop (Point 2). Now Place(1)
>queues an activity at Place(0) (Point 3). But since Place(0) is
>executing the endless-loop, it will never execute the queued activity,
>like above.
>
>The easiest way to get the program running is by starting it with two
>threads (export X10_NTHREADS=2), but that would be boring, wouldn't it? =)
>
>You can use "Runtime.probe()" to explicitly interrupt a running activity
>and run another, queued activity. I invoked the call in the source code
>already, the code should now behave as expected. However, keep in mind,
>that acitivity ordering in X10 does not guarantee fairness or any kind
>of order.
>
>The same effect (an activity blocking a thread) can be observed when you
>use "when(...)". I think you can learn a little bit more about ordering
>by observing the following source code:
>
>public class Hello
>{
> public static def main(args:Rail[String])
> {
> Console.OUT.println(here + ": start.");
> for (var i:Long = 0; i < 10; ++i)
> {
> val printI:Long = i;
> async { Console.OUT.println(here + ": " + printI); }
> }
> Console.OUT.println(here + ": end.");
> }
>}
>
>Hope i could help. Have a nice weekend.
>
>Cheers,
>Marco
>
>
>Am 23.08.2014 um 04:23 schrieb 王辰:
>> Thank you all, guys. I really learned a lot.
>> But now i'm runing into a new problem.
>>
>> I have a infinite loop in Place(0) and i'm using *at(Place(0)){...}* in
>> Place(1).
>> I don't konw why the code in *at(Place(0)){...}* will never be invoked.
>>
>> Code:
>> public class Hello {
>> public static def main(args:Rail[String]) {
>> at(Place(1)) async test();
>> while(true) {}
>> }
>>
>> public static def test() {
>> at(Place(0)) async {
>> val a = 1+2; // nverer be called
>> Console.OUT.println("a:"+a);
>> Console.OUT.flush();
>> }
>> }
>> }
>>
>> (I'm using x10_2.4.3 for mac)
>>
>>
>>
>> At 2014-08-22 10:25:45, "Vijay Saraswat" <vi...@saraswat.org
>> <mailto:vi...@saraswat.org>> wrote:
>>
>> Tiago you could also use implicit clocks. (Havent checked, should
>> work :-).)
>>
>> A clocked finish S is just like a finish S except that a clocked is
>> implicitly spawned, and dropped after S is executed (and before the
>> waiting for S commences). In S, a clocked async A registers async A
>> on this (implicit) clock. As usual, Clock.advanceAll() can be used
>> by each registered activity to advance the clock.
>>
>> public class Hello {
>>
>> public static def main(args:Rail[String]) {
>>
>> val iter:Long = Long.parse(args(0));
>> val hello = new Hello();
>> val start:Long = System.currentTimeMillis();
>> val each = iter/Place.MAX_PLACES;
>> // val c = Clock.make();
>> clocked finish {
>> for (var i:Long = 0; i < Place.MAX_PLACES; ++i) {
>> at (Place(i)) clocked async /*clocked(c)*/
>> {Clock.advanceAll(); hello.test(each); }
>> }
>> // c.drop();
>> }
>> val stop:Long = System.currentTimeMillis();
>> Console.OUT.println( here + ": time consumed = "
>> + (stop - start) + " ms.");
>>
>> }
>>
>> private def test(val iter:Long) {
>>
>> for(var i:Long=0;i<iter;i++) {
>>
>> //Console.OUT.println("test,"+here);
>>
>> }
>>
>> }
>> }
>>
>>
>> On 8/22/14, 9:02 AM, Tiago Cogumbreiro wrote:
>>> Here is the updated example on using clocks to make sure both
>>> tasks are up and running in their respective places before executing.
>>>
>>> public class Hello {
>>>
>>> public static def main(args:Rail[String]) {
>>>
>>> val iter:Long = Long.parse(args(0));
>>> val hello = new Hello();
>>> val start:Long = System.currentTimeMillis();
>>> val each = iter/Place.MAX_PLACES;
>>> val c = Clock.make();
>>> finish {
>>> for (var i:Long = 0; i < Place.MAX_PLACES; ++i) {
>>> at (Place(i)) async clocked(c) {c.advance();
>>> hello.test(each); }
>>> }
>>> c.drop();
>>> }
>>> val stop:Long = System.currentTimeMillis();
>>> Console.OUT.println( here + ": time consumed = "
>>> + (stop - start) + " ms.");
>>>
>>> }
>>>
>>> private def test(val iter:Long) {
>>>
>>> for(var i:Long=0;i<iter;i++) {
>>>
>>> //Console.OUT.println("test,"+
>>> here);
>>>
>>> }
>>>
>>> }
>>> }
>>>
>>>
>>>
>>>
>>>
>>> On 22 August 2014 13:56, Josh Milthorpe <josh.miltho...@gmail.com
>>> <mailto:josh.miltho...@gmail.com>> wrote:
>>>
>>> Hi Wang,
>>>
>>> using 'async' is the correct way to create an asynchronous
>>> activity, and 'at (p) async' is the correct way to create a
>>> remote activity. So your code is already correctly
>>> parallelized for two places.
>>>
>>> The reason your output is always in the same order is the
>>> buffering of output streams. Calling Console.OUT.println(...)
>>> at a place performs a buffered write to stdout for that
>>> place. When the buffer is flushed it is sent to place 0 (or
>>> the launcher process) and combined in the stdout for the
>>> program. In your code, no place ever completely fills its
>>> buffer, so all the buffers are flushed in order when the
>>> program terminates.
>>>
>>> If you want to force the buffer to be flushed, use
>>> Console.OUT.flush();
>>> after each call to println. However, please be aware that X10
>>> does not guarantee any ordering of output between activities
>>> or places. Therefore the interleaving of output may still be
>>> different from the order in which the activities call
>>> Console.OUT.println(). If you do need to enforce ordering
>>> between activities, use a synchronization construct such as
>>> finish or clocks.
>>>
>>> Cheers,
>>>
>>> Josh
>>>
>>>
>>> On 22 August 2014 02:54, 王辰 <wang...@163.com
>>> <mailto:wang...@163.com>> wrote:
>>>
>>> Hello everyone, i'm new to x10.
>>> I have a little problem about parallelization, here's my code:
>>>
>>> public class Hello {
>>>
>>> public static def main(args:Rail[String]) {
>>>
>>> val hello = new Hello();
>>>
>>> at (Place(1)) async hello.test();
>>>
>>> at (Place(0)) async hello.test();
>>>
>>> }
>>>
>>> private def test() {
>>>
>>> for(var i:Int=0n;i<100n;i++) {
>>>
>>> Console.OUT.println("test,"+here);
>>>
>>> }
>>>
>>> }
>>>
>>>
>>> I thought the output should not be the same if i run it
>>> several time.
>>> But it was always the same:
>>>
>>> Place(0)
>>> Place(0)
>>> ...
>>> Place(0)
>>> Place(0)
>>> Place(1)
>>> Place(1)
>>> ...
>>> Place(1)
>>> Place(1)
>>>
>>> Can anyone tell me is it so and what should i do to
>>> implement real parallelization?
>>>
>>> Thanks.
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Slashdot TV.
>>> Video for Nerds. Stuff that matters.
>>> http://tv.slashdot.org/
>>> _______________________________________________
>>> X10-users mailing list
>>> X10-users@lists.sourceforge.net
>>> <mailto:X10-users@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/x10-users
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Slashdot TV.
>>> Video for Nerds. Stuff that matters.
>>> http://tv.slashdot.org/
>>> _______________________________________________
>>> X10-users mailing list
>>> X10-users@lists.sourceforge.net
>>> <mailto:X10-users@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/x10-users
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Slashdot TV.
>>> Video for Nerds. Stuff that matters.
>>> http://tv.slashdot.org/
>>>
>>>
>>> _______________________________________________
>>> X10-users mailing list
>>> X10-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/x10-users
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Slashdot TV.
>> Video for Nerds. Stuff that matters.
>> http://tv.slashdot.org/
>>
>>
>>
>> _______________________________________________
>> X10-users mailing list
>> X10-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/x10-users
>>
>
>------------------------------------------------------------------------------
>Slashdot TV.
>Video for Nerds. Stuff that matters.
>http://tv.slashdot.org/
>_______________________________________________
>X10-users mailing list
>X10-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/x10-users
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
X10-users mailing list
X10-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/x10-users
