Search code examples
javamultithreadingthreadpoolexecutor

WorkStealingPool vs. FixedThreadPool in a NON fork join scenario


Usually I was told that the WorkStealingPool implements the work-stealing algorithm, that helps to balancing the thread’s workload.

But I don't think a FixedThreadPool is unbalanced. Every thread polling one task from a blocking queue when it is stale looks balanced to me.

Any advantage of WorkStealingPool over FixedThreadPool, and could I say that I should never think about work stealing, if the tasks are not recursive?


Solution

  • But I don't think a FixedThreadPool is unbalanced. Every thread polling one task from a blocking queue when it is stale looks balanced to me.

    That is fairly well balanced on average when the number of tasks is much larger than the number of threads. It is also well balanced when the number of threads divides the number of tasks and every task takes about the same amount of time.

    Under other circumstances, the work of a FixedThreadPool may not be very well balanced. The extreme would be when the pool has multiple threads but only one task -- then one thread does all the work while all the others stand idle.

    Any advantage of WorkStealingPool over FixedThreadPool,

    Yes. For tasks that can be structured suitably, the work-stealing pool can, on average, distribute the overall work more evenly across the multiple threads of your pool.

    and could I say that I should never think about work stealing, if the tasks are not recursive?

    You could say anything, but that doesn't make it so. Structuring your tasks to support work stealing is pretty easy for those implementing divide-and-conquer approaches, which are typically recursive, but it does not in any way rely on your tasks to be recursive.

    It would be more accurate to say that you should never consider work stealing except when any part of the work of your tasks can divided among multiple concurrently-running subtasks.