28 lines
1.7 KiB
Markdown
28 lines
1.7 KiB
Markdown
# Problem 8.1: Compare `ForkJoinPool` to `ThreadPoolExecutor`
|
|
|
|
According to the lecture, the two types of Java thread pools are optimized for different application
|
|
scenarios:
|
|
|
|
- `ForkJoinPool` for task that are mutually dependent, created by other tasks, short, rarely blocking (i.e. computation-intensive)
|
|
- `ThreadPoolExecutor` for tasks that are mutually independent, submitted "from the
|
|
outside", long, sometimes blocking
|
|
|
|
Can you give justifications for these five differences (many vs. few tasks, dependent vs. independent
|
|
tasks, created by the application vs. created by other tasks, short vs. long tasks, rarely vs. frequently
|
|
blocking tasks) when considering the different queuing behavior and also the `join()` operation of
|
|
the ForkJoinTask? Formulate one sentence for each of the five differences, e.g. "`ForkJoinPool`
|
|
is better suited to independent tasks because ...".
|
|
|
|
## Answer:
|
|
|
|
`ForkJoinPool` is better suited for mutually dependent tasks because the `join()` allows for efficient execution of child tasks without blocking the thread
|
|
|
|
`ThreadPoolExecutor` is better suited for tasks which can block because blocking threads can make `ForkJoinPool`s much more inefficient.
|
|
|
|
`ThreadPoolExecutor` is better suited for long running tasks, because `join()` executes another task while waiting for the current one to finish, therefore possibly waiting longer than strictly necessary.
|
|
|
|
`ForkJoinPool` is better suited for short running tasks because it uses seperate stacks for each thread, therefore avoiding synchronization overhead when taking new tasks.
|
|
|
|
Tasks usually create other tasks if they are dependent on that task, so since `ForkJoinPool` is better suited for mutually dependent tasks, it is also better suited for tasks that create other tasks.
|
|
|