[concurrency-interest] Fork/Join Use cases

Doug Lea dl at cs.oswego.edu
Fri Dec 12 08:37:31 EST 2014

On 12/11/2014 09:16 PM, Richard Warburton wrote:
> Something I have noticed with fork/join is the absence of clear-cut and
> common motivating examples and use cases.

One realm is aggregate operations; many of the most common ones
(map, filter, reduce, collect, etc) now (in jdk8) prepackaged in.
Stream.parallel(). But also used by others for custom in-core BigData
algorithms and the like. (Plus, the underlying work-stealing
scheduler is useful in other contexts.)

> everytime I try to fit a parallel programming problem into the fork/join
> model in my head it doesn't seem to offer me much over the ability to run a
> series of parallel threads.

Right. The main reason FJ exists in the JDK is to provide a framework
for developing portable general-purpose versions of such programs,
that includes ways of controlling how many threads are used,
expressing and managing granularity thresholds,  load
balancing when some cores are busy doing other things,
nested parallelism, combining/reducing results,  and so on.

Some people who don't care about any of these issues, and are
content with ad-hoc programs that run well on particular computers
don't have much motivation to use FJ. On the other hand, FJ can help
in the discovery of parallel techniques by encouraging design
via structured parallel divide-and-conquer, which is often a
productive approach.


More information about the Concurrency-interest mailing list