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.
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
--dave
>
> Am 10.03.2015 um 13:47 schrieb David P Grove:
> > Marco Bungart <m.bung...@gmx.net> wrote on 03/10/2015 05:11:27 AM:
> > >
> > > the appended program shows nondeterministic behaviour. Sometimes it
> > > finishes, most times it runs into an endless loop. It happends with
both
> > > native and managed X10. I am using the repository revision 29129 of
X10,
> > > java 1.8.0_40 and gcc 4.8.2.
> > > With an older version of X10 (2.4.3.2), the program terminates just
fine.
> > > One observation I was able to make: the program terminated only, if
> > > X10_RESILIENT_MODE was set to 1. If it was unset, I was not able to
> > > observe termination (but this could be pure coincidence...).
> > >
> > > Environment variables and compile-command used (command line
parameter
> > > only prevents flooding your console):
> > >
> > > $ >export X10_NPLACES=2 X10_NTHREADS=1
> > > $ >x10c++ ../src/Hello.x10 -o Hello && ./Hello 5000000
> > >
> > > Could someone explain to me, what is going wrong or what changed?
> > >
> >
> > Hi Marco,
> >
> > We'll take a look. But at first glance at your code and without
running
> > it, I would expect it to get into an infinite loop almost all the time.
> > You have asked for 1 thread per place and you have the one thread in
> > Place(0) spinning executing a busy wait loop. I suspect what has
> > changed since 2.4.3.2 is that the runtime has gotten better at not
> > having extra active threads, which in older versions may have provided
> > the surplus execution resources in Place(0) to make this program not
get
> > stuck in the busy wait loop.
> >
> > The proper way to write this program would be to have the waiting
> > activity be blocked on a when(plh().finished) and have the releasing
> > activity do atomic plh().finished = true;
> >
> > --dave
> >
> >
> >
>
------------------------------------------------------------------------------
> > 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
