[concurrency-interest] ForkJoinExecutor.invoke and ForkJoinTask.invoke

Doug Lea dl at cs.oswego.edu
Sat Dec 15 09:46:01 EST 2007


Doug Lea wrote:
> 
> The issue is whether ForkJoinPool (FJP) invoke(task) should
> (as now) serve as gateway between FJ and non-FJ threads,
> or whether it should check to see if caller is an FJ thread
> and if so act like task.invoke().
> The main visible difference is that the former blocks
> on join, while the latter helps on join (i.e., may execute
> that or some other task until done). But there is another
> difference that some people may need to rely on:
> FJP.invoke schedules tasks for execution in submission order,
> while plain task.invoke executes whenever it wants to
> (which turns out to always be  "immediately").
> 

There's an (in retrospect) obvious solution:
ForkJoinPool.invoke should allow helping (non-blocking) joins
when called from FJ tasks, but need not immediately
invoke the task, but instead process tasks in pool submission
order until completion. This is not only what people would
intuitively expect given the ForkJoinPool and ForkJoinTask
specs, but also avoids thread depletion dues to unnrecessary
blockages.

Revised versions that do this are now in CVS and jsr166y.jar.

While I'm at it: they also include some documentation clarification
in response to another (off-list) question. For ForkJoinTask t,
t.isDone() guarantees only to *eventually* return true upon
t's completion. This means that for example, concurrent calls
to t.isDone() from other tasks/threads may transiently disagree
about whether t.isDone() yet, but will always eventually agree.
Usages where this issue arises though are a little suspicious;
normally you want to call join() rather than polling isDone().

-Doug


More information about the Concurrency-interest mailing list