Hi, sorry for the late reply. Works like a charm =) Thank and have a nice weekend, Marco
Am 13.03.2015 um 03:08 schrieb David P Grove: > Try picking up https://sourceforge.net/p/x10/code/29171 > > I think this should restore the X10 2.5.0 and earlier behavior of > Runtime.probe() > > --dave > > Inactive hide details for Marco Bungart ---03/12/2015 06:35:55 AM---Hi, > sorry me again.Marco Bungart ---03/12/2015 06:35:55 AM---Hi, sorry me again. > > From: Marco Bungart <m.bung...@gmx.net> > To: Mailing list for users of the X10 programming language > <x10-users@lists.sourceforge.net> > Date: 03/12/2015 06:35 AM > Subject: Re: [X10-users] Nondeterministic behaviour of Runtime.probe() > > ------------------------------------------------------------------------ > > > > Hi, > sorry me again. > > The appended code goes in the same kind of endless-loop as the code > before when X10_NUM_IMMEDIATE_THREADS is set to 0 and X10_RESILIENT_MODE > is set to 1. I think that X10_RESILIENT_MODE=1 does start a kind-of > immediate thread, which probes the network. > Can someone tell me, what export X10_RESILIENT_MODE=1 exacly does? Is > there another workaround to this behaviour than using @Immediate? > > What I cannot explain: when you remove line 29 to 41 (busy-waiting loop > with probe), Place(1) gets stuck behind the at(...) async {...} (line 23 > to 27). @Immediate, setting X10_NUM_IMMEDIATE_THREADS a value > 0 or > setting X10_RESILIENT_MODE to 0 fixes this issue. > > All this tests were done with revision 29160. > > Cheers, > Marco > > Am 10.03.2015 um 19:22 schrieb David P Grove: > > David P Grove/Watson/IBM wrote on 03/10/2015 11:05:31 AM: > > > > > From: David P Grove/Watson/IBM > > > To: Mailing list for users of the X10 programming language <x10- > > > us...@lists.sourceforge.net> > > > Date: 03/10/2015 11:05 AM > > > Subject: Re: [X10-users] Nondeterministic behaviour of Runtime.probe() > > > > > > Marco Bungart <m.bung...@gmx.net> wrote on 03/10/2015 09:04:24 AM: > > > > > > > > your answer surprises me a little. Up until now I thought that > > > > Runtime.probe() unloads the current task (activity) from a > thread, so > > > > another task (activity) can use this thread and therefore I > expected, > > > > that the inner at (Place(0)) async {...} would be executed at some > > > > point, even if this place has only one thread. What exactly does > > > > Runtime.probe() do then? > > > > > > Runtime.probe() simply allows the underlying x10rt network layer to > > > use the thread to "advance" by progressing the sending of outgoing > > > messages that have been blocked due to nwtwork flow-control and/or > > > receive any incoming messages. > > > > Actually, this is not right. It does something in between what you and > > I thought. In addition to advancing the network, Runtime.probe also > > runs any pending tasks on the Worker's Deque. These may be other > > activities previously produced by the worker locally and pushed to its > > Deque or messages from the network that this worker has received. > > However, it does not attempt to steal work from other workers or to take > > work from the submittedJobs Deque in the Pool. > > > > In X10 2.5.1, we introduced an immediate worker thread that ends up > > doing most of the interaction with the network. When it receives a > > normal (non-immediate) async from the network, it puts it in the > > submittedJobs Deque of the Pool. So, with high probability, when the > > normal worker thread calls probe() in your spin loop, it doesn't pull > > anything from the network because the immediate thread has already > > grabbed it and put it on the submitedJobs deque. Runtime.probe is not > > looking at the submittedJobs deque, so once this happens your program is > > stuck. The message has been received and enqueued for processing, but > > probe() doesn't look in the right place to find it. We'll have to > > figure out whether or not this is the appropriate behavior for poll(). > > > > If you set X10_NUM_IMMEDIATE_THREADS=0, you can prevent this from > > happening, and at least for me the program then terminates reliably > > without @Immediate asyncs. > > > > --dave > > > > > > > > If the incoming messages are "normal" asyncs, calling Rutime.probe() > > > does not actually schedule them. It simply gets the message out of > > > the network layer and pushes it on the Worker's Deque for later > > > execution (either by this Worker when the current activity > > > terminates, or to be stolen by other Workers). > > > > > > However, for "immediate" asyncs (ones annotated by > > > x10.compiler.Immediate), the message body is executed within the > > > call to Runtime.probe(). So another way to get the test program you > > > wrote to work would be to annotate the incoming remote async's body > > > with @Immediate and then let it execute within the call to > > > Runtime.probe(). This is a somewhat delicate thing to do, since > > > immediate asyncs need to be non-blocking and you need to take care > > > to not recur too deeply or you may get a StackOverflowException. > > > Unless this is a performance critical piece of code, it would be > > > better to write with atomic/when then with probe/immediate > > > > > > > > > > > > ------------------------------------------------------------------------------ > > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > > by Intel and developed in partnership with Slashdot Media, is your > hub for all > > things parallel software development, from weekly thought leadership > blogs to > > news, videos, case studies, tutorials and more. Take a look and join the > > conversation now. http://goparallel.sourceforge.net/ > > > > > > > > _______________________________________________ > > X10-users mailing list > > X10-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/x10-users > > > [attachment "Hello.x10" deleted by David P Grove/Watson/IBM] > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub > for all > things parallel software development, from weekly thought leadership > blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. > http://goparallel.sourceforge.net/_______________________________________________ > X10-users mailing list > X10-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/x10-users > > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > > > > _______________________________________________ > X10-users mailing list > X10-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/x10-users > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ X10-users mailing list X10-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/x10-users
