[concurrency-interest] ForkJoinPool.ManagedBlocker examples

Doug Lea dl at cs.oswego.edu
Tue Feb 22 19:26:57 EST 2011


On 02/22/11 17:27, Alex Miller wrote:
> it would be helpful to add a note in the docs that block()
> and isReleasable() will only be called from the thread that invokes
> managedBlock().

Sure. Now (after a code update commit) is a good time to
incorporate documentation improvements. I added a sentence
to the middle of ManagedBlocker doc, now reading:

      * Interface for extending managed parallelism for tasks running
      * in {@link ForkJoinPool}s.
      *
      * <p>A {@code ManagedBlocker} provides two methods.  Method
      * {@code isReleasable} must return {@code true} if blocking is
      * not necessary. Method {@code block} blocks the current thread
      * if necessary (perhaps internally invoking {@code isReleasable}
      * before actually blocking). These actions are performed threads
      * invoking {@link ForkJoinPool#managedBlock}.  The unusual
      * methods in this API accommodate synchronizers that may, but
      * don't usually, block for long periods. Similarly, they allow
      * more efficient internal handling of cases in which additional
      * workers may be, but usually are not, needed to ensure
      * sufficient parallelism.  Toward this end, implementations of
      * method {@code isReleasable} must be amenable to repeated
      * invocation.
      *
>
> A separate question, why are the ForkJoin classes no longer in a
> forkjoin sub-package and just mixed into java.util.concurrent?  Seems
> weird.

It could have gone either way, but it is no weirder than having
ThreadPoolExecutor and FutureTask being in j.u.c:
Like them, a ForkJoinPool is "just" a special kind of Executor, and a
ForkJoinTask a kind of Future.

-Doug


More information about the Concurrency-interest mailing list