[concurrency-interest] Fork/Join Use cases

Doug Lea dl at cs.oswego.edu
Mon Dec 15 12:16:43 EST 2014

On 12/15/2014 11:29 AM, Richard Warburton wrote:

> So using fork/join is one approach to implementing such algorithms. Another
> would be to use a threadpool, possibly even a work-stealing style thread pool
>  from fork/join, but manage the problem decomposition and result aggregation
>  yourself. This seems to be the approach taken by the GS-Collections
> framework whose benchmarks suggest is very competitive performance-wise to
> parallel streams and have a similar style of API.

That's a java.util, not java.util.concurrent question :-)

> The other side of this coin is that whenever I've seen people deploy some
> kind of big-data algorithm a significant problem isn't the computational part
> of that algorithm as much as it is querying the data from an external source
> which may involve I/O.

Sometimes. (See my other post this morning.)

> Its perfectly understandable to want to provide a general framework here and
> I'm sympathetic to these motivating concerns, but I'm asking about which
> situations where you think delegating these responsibilities to the framework
> makes things sense over managing them by hand. Often people try to fit the
> wrong type of problem into a framework and its harder to manage the impedance
> mismatch than solve the problem.

The primary audience for j.u.c has always been infrastructure,
middleware, and framework developers. The main criterion is whether
providing a standard API (plus at least one high quality implementation)
will be helpful to those developing layered software. (Including
usages in other parts of JDK.)

Initially, I had guessed that the audience size for FJ would be about
the same as, for a random example, SynchronousQueue. As opposed to
components like ConcurrentHashMap that came to be commonly used by
application programmers as well.

In fact, FJ was initially triaged  out of (JDK5) j.u.c. Similarly for
completion-based processing APIs. But they were added when it became
clear that developers were starting to solve similar problems
in gratuitously different ways, and so deserved a common basis.

Still, there will always be people using only the lower-level
components to build alternative/custom versions of middle-level ones.
There are as many specialized variants of jdk concurrent components
out there as there are specialized non-concurrent variants of
other jdk components. (For example, GS collections includes some of
all of these.)

> Again I'm not trying to be too negative on F/J here as much as satisfying my
> curiosity and making sure that I'm not missing something in my
> understanding.

My sense is that you are mostly asking why more people express
concern about the existence of ForkJoinPool than SynchronousQueue.
It might just be the sexiness factor. To some people, FJP seems like
something cool that you should know about, even if you have no
reason to use it.


More information about the Concurrency-interest mailing list