[concurrency-interest] Fork/Join Use cases
richard.warburton at gmail.com
Mon Dec 15 11:29:00 EST 2014
Thanks for taking the time to reply.
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.)
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. Can
you be more specific about the benefits here? Perhaps there's something
that GS-Collections has had to reimplement multiple times that you can
point to in their architecture or source code that Streams are getting for
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.
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
>> 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.
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest