[concurrency-interest] Fork-Join and getSurplusQueuedTaskCount
dl at cs.oswego.edu
Sun Aug 31 10:25:06 EDT 2014
On 08/31/2014 09:35 AM, Kasper Nielsen wrote:
> I'm trying to figure out if ForkJoinTask#getSurplusQueuedTaskCount is worthwhile
> to use for basic array-like processing. RecursiveAction comes with an example
> where it is used. But haven't seen it used in practice anywhere. For example,
> the java.util.stream implementation does not make use of it.
If you have good size estimates, it is generally best to use them
for granularity control; normally aiming to create 4 to 8 times
more total tasks than threads/cores/parallelismLevel for the sake
of load balancing. Method getSurplusQueuedTaskCount is available
as a fallback when you don't have any other basis of estimation.
This might occur for example in graph traversal algorithms
where you don't know anything about expected amount of work.
The method relies on statistical regularities, and in the
aggregate works better than all alternatives I know of.
(We do have a few test/demos of its use in the "loops" CVS.)
But it can encounter more run-to-run variance that you would
see with size estimates, if you had them. Since java.util.stream
normally relies on sizes anyway, it doesn't use it, although there
are a few cases where it might be worth exploring.
(I agree that it might be a little misleading that we
demonstrate getSurplusQueuedTaskCount in javadocs,
just for the sake of providing an example, in a context
where you probably wouldn't choose to use it. Maybe we should
at least add a comment to this effect.)
More information about the Concurrency-interest