Java Fork/Join vs Multithreading in the Multicore World

Question

Couldn't just get why Fork Join is better in terms of multicore utilisation.

An example to illustrate this (Just a theoretical one):

I have an array of webservice endpoints: [E1, E2, E3, E4]

Let's assume each endpoint returns a number.

I have to then sum up the total and return the result.

With this simple story in mind.

I have 2 options:

1. ExecutorService fixedThreadPool of 4 and span these 4 calls in parallel.
2. Fork Join framework with 4 tasks.

Assume I have 4 cores.

With Executor service, 4 JVM threads are created and AFAIK, it's completely upto the OS to schedule them on the same core or multiple cores.

If they're scheduled on the same core, then we have the problem of under-utilised cores.

If they're scheduled on different cores, then we're laughing!

All I'm trying to get at is this bit of uncertainty around using multiple cores.

How does Fork Join get around this? Does it internally pass some kind of magical instructions to the OS to use multiple cores?

If my above example is not relevant to draw a comparison between Fork Join vs Executors, how does Fork Join claim that it utilises cores much efficiently than traditional multithreading.

Answer 1

Fork/join is a higher level of abstraction. Usually, if you use higher-level libraries to solve your problem, then you will solve your problem with fewer lines of new code. That's always a Good Thing.

Higher-level usually means more specialized though. Fork/join may or may not fit your problem. If it doesn't fit, then you could waste a lot of effort and make an awful mess by trying to make it fit.

If it does fit though, and you don't use it, then chances are, you will be re-inventing some wheel. That's never a good thing.

Answer 2

Fork/Join is faster than simple ExecutorSevice only if the task can be recursively subdivided into smaller tasks. In this case Fork/Join can use work stealing in order to ensure that all CPUs are optimally used.

In your case it is not faster.

EDIT: in addition to work stealing, the scheduling of the tasks can be also faster. As the Wikipedia puts it:

The lightweight threads used in fork–join programming will typically have their own scheduler (typically a work stealing one) that maps them onto the underlying thread pool. This scheduler can be much simpler than a fully featured, preemptive operating system scheduler: general-purpose thread schedulers must deal with blocking for locks, but in the fork–join paradigm, threads only block at the join point.