6

In a ForkJoinPool ForkJoinTask, does the current worker thread participate in work stealing?

I have read implications that a fork join pool can work steal from blocked or waiting threads. The current worker seems an obvious candidate. Once the worker calls .join() on another task, then that task is essentially blocked.

On the other hand, I see many articles that imply different conclusions. For example, the general consensus that the current worker thread should do work before waiting for forked tasks.

There are a few articles that discuss the use of ForkJoinTask.getSurplusQueuedTaskCount as a method of balancing the work in the queue by having the current worker do some of the work. If the current worker is also stealing, then this doesn't seem necessary.

Naturally, I would like to maximize thread operations and keep all workers running maximally. Understanding if the current thread also steals work (for example when .join is called) will help to clarify.

Bill Door
  • 18,272
  • 3
  • 32
  • 37
  • You need a specific type of problem for it to be maximum see http://stackoverflow.com/questions/7926864/how-is-the-fork-join-framework-better-than-a-thread-pool – Adam Gent Oct 15 '15 at 04:27
  • 1
    I wrote one of those articles and I can guarantee you that join() doesn't result in work-stealing http://coopsoft.com/ar/Calamity2Article.html#join Work-stealing is only valid when the deque is empty. Personally, I would not micromanage the framework with getSurplus.... etc. – edharned Oct 15 '15 at 14:37

1 Answers1

2

It is the responsibility of the ForkJoinPool to manage threads. Client code should feed it tasks, not micromanage the threading. Note that tasks and threads are two different things; tasks are units of work to be executed, and threads execute that work.

ForkJoinTask.compute() should fork() into smaller subtasks if the task is large enough to benefit from running parts of the task in parallel, and simply process the task if the task is small enough that it would better be run in a single thread. If the work turns out to be more than expected, it can fork() some of the work and do the rest of it.

If ForkJoinTask.compute() forks into smaller subtasks, it can call join() before returning. The ForkJoinPool will then either free the thread to work on other tasks, or spawn a temporary thread to work on other tasks to ensure the available parallelism is fully utilized.

I think it's reasonable to assume that the appropriate number of worker threads are kept busy for as long as there are uncompleted tasks, unless you explicitly block the thread in the compute() method.

The Sun tutorial provides more specifics on how to use these classes:

https://docs.oracle.com/javase/tutorial/essential/concurrency/forkjoin.html

Warren Dew
  • 8,790
  • 3
  • 30
  • 44