Hi David,
thanks for the answer. The last bit (about X10_NUM_IMMEDIATE_THREADS)
helps a lot.
I think there should definetly a way for any activity to interrupt
itself and pull work from (other) queues. I do not know enough about the
interior of the runtime (e.g. the different Dequeues) to make a
well-informed decision, but for me it feels more organic when i am able
to "access" all pending acitivities in a program. The situation gets
especially tricky when you are writing a program with an actor-model
since you might get messages from other places at any point in time. In
these situations the ability to access all acitivities is pretty much
crucial.
On a sidenote: is there a document describing the runtime-implementation
with the different dequeues?
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
>
------------------------------------------------------------------------------
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
