Whats the benefit to use workstealing from ForkJoin rather than just ordinary thread pool's queue? is the "workstealing" from ForkJoinPool better then just take tasks from the thread pool's queue? Isn't it stealing?
Asked
Active
Viewed 181 times
1
-
1Does this answer your question? [How is the fork/join framework better than a thread pool?](https://stackoverflow.com/questions/7926864/how-is-the-fork-join-framework-better-than-a-thread-pool) – kasptom Nov 07 '21 at 10:56
-
1...or this, also a nice explanation: https://stackoverflow.com/questions/33448465/threadpoolexecutor-vs-forkjoinpool-stealing-subtasks – Petr Janeček Nov 07 '21 at 10:56
1 Answers
0
ForkJoinPool is designed for Recursive Actions. This might for example be a divide-and-conquer algorithm like MergeSort. In such an algorithm, one Thread would usually wait for the children to finish.
This is where "workstealing" comes in. The work would be stolen from the waiting Thread by the ones that actually have work to do.
If you have a fixed amount of Threads that will not spawn new Threads, you should just use a normal ExecutorService ThreadPool.

Simon Weid
- 51
- 3