Does Java 7 fork/join guarantees executing thread in seperate CPU

Question

Recently, I came to know about the Java 7 fork/join framework - what I learned is that it could be useful for divide-and-conquer like problems.

My question is, does the framework guarantees executing threads on separate CPUs? Or is it event possible to instruct the threads I create using classes of concurrent package to run on separate CPUs available in my server?

Barnett

Answer 1

It'll be built upon the standard JVM concurrency primitives, in which case they will (eventually) be scheduled onto real OS threads. You cannot guarantee that your OS scheduler is going to schedule threads onto separate CPUS, although it's quite likely in most instances.

Trying to guess what a concurrent scheduler is going to do at runtime is a really bad idea. Just assume that you will be able to make use of no more than as many CPUs as you have active threads, and don't try to second-guess the runtime behaviour unless you're trying to do a particular kind of very low-level optimisation.

Ahumada

Thanks Gian. Previously I was using basic threads to load something from db, I did that in separate threads. Achieving that with F/J will give no extra benefit I guess? – Barnett

FJ is not thinked for I/O based tasks, but for CPU bounded algorithms. So rule of thumb could be: I/O go for thread, CPU use F/J – Frond

F/J is unlikely to provide specific performance benefits, but it might allow you to structure your concurrent code in ways that make it easier to understand, optimize, or reason about. – Ahumada

Gian, partially disagree. If used for divide et impera CPU bounded algorithms, FJ gives you the benefits of splitting work on multiple threads and so getting benefits from parallel execution. Of course if used under right assumptions. – Frond

How would that give you additional performance benefits over and above using threads? Of course going parallel is going to provide performance benefits in many instances, but it's unlikely that fork/join is going to provide objectively better performance than threading (or vice-versa), all other things being equal. – Ahumada

Im surprised noone mentioned context switching. The threads are being handlend by switching to available resources so if one task is executed and the same processor is the one being switched to, that processor handles the task. The answer is no guaruntee but why would you need one anyway? – Christoper

Answer 2

At least it will do its best. The fork/join framework is designed to take advantage of multiple processors. By default ForkJoinPool is created with the number of worker threads equal to the number of processors.

Contiguous

"The fork/join framework is designed to take advantage of multiple processors" - what about using basic Threads? If I use basic threads or thread-pool will it take advantage of multiple processor? – Barnett

Basic threads are a bit harder to program. With Fork/Join you have simple primitives and all the thread work is done behind the scenes. You have just to create the ForkJoinPool and extend the RecursiveTask class – Frond

@trapo, I was concerned about whether basic threads are supposed to run on separate CPUs by the scheduler, I mean in this sense (scheduling threads on individual CPU) does basic threads have any difference with F/J? – Barnett

Answer 3

Does the framework guarantee executing threads on separate CPUs?

No. No guarantees.

Or is it event possible to instruct the threads I create using classes of concurrent package to run on separate CPUs available in my server?

Not using the standard Java libraries. In theory, anything is possible (up to the limit of what the OS allows) if you are willing to dig around in the native layers of the JVM. But you will be in for a lot of unnecessary work / pain.

My advice:

• You probably don't need that level of control. (IMO) it is likely that the default behaviour of the native thread scheduler is "good enough" to achieve satisfactory performance.

• If you really need that level of control, you would be better off using a different programming language; i.e. one where you can interact directly with the host OS'es native thread scheduler. You may even need a different operating system ...

Actinouranium

So say my multi-thread app is not divide-n-conquer in nature or it does not do work-stealing (the concept I am not clear totally) - doing it with F/J will have no extra advantage than doing it with basic Threads? – Barnett

Work stealing means that a RecursiveAction is allocated by a thread and that could be executed on another thread of the ForkJoinPool that is idle, moving that action from the private queue of the first thread to the queue of the other thread. – Frond

Thanks @trapo, can you kindly give some piece of code which uses work stealing? – Barnett

Yep, my own question (and answer on SO): #14077390 Beware that you don't use workstealing, but observe it. – Frond

If you are interested in F/J, i wrote a little post on it. The post is in italian, but at the end you can find a list of userful links on the subject: cosenonjaviste.it/…. There's also a class you can try that show how tasks are moved from a thread to another. – Frond