[plt-dev] Parallel Futures Release

Right.  You won't have the problem Sam talks about where you've forced a
computation to finish on a separate OS thread than the one you originally
started on.  Code in a future will always execute on the same OS thread
(except for the unsafe primitive invocations), even if you touch it before
it's finished.  In that case, the runtime OS thread will do whatever unsafe
work was blocking the future, then signal the future OS thread that it can
resume.  Then the runtime OS thread blocks waiting for the future thread to
terminate (or ask for another primitive invocation).

One thing to worry about is touching a future before a parallel thread has
had a chance to discover it, in which case the whole future will actually be
run on the runtime thread.  I don't think this would really ever be a
problem in practice, however, because if your code wants to touch the future
that quickly, you probably didn't need to do the computation in parallel in
the first place.

The operating system can arbitrarily decide to move threads from one
processor to another but there's little we can do about that.  We can use
affinity masking to politely suggest that the OS keep threads bound to
specific processors/cores, but even then it's still
free to schedule them however it wants.

-James

On Sun, Dec 13, 2009 at 9:10 AM, Robby Findler
<robby at eecs.northwestern.edu>wrote:

> On Sun, Dec 13, 2009 at 8:40 AM, Sam TH <samth at ccs.neu.edu> wrote:
> > I thought that when a future gets `touch'ed, if
> > it isn't finished, the remainder of the computation runs in the
> > continuation (and thus thread) of the `touch'.  If I'm wrong about
> > that, then my worries are assuaged.
>
> That's roughly what happens when the future was blocked (technically,
> it does some rendez vous with the runtime thread instead of copying
> the state over, but that's something that shouldn't really matter from
> the api level), but when the future is not blocked, it just keeps
> running merrily along.
>
> Robby
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20091213/5577baec/attachment.html>