Java - relationship between threads and CPUs

Question

I am pretty new to multithreading, and I am working on a project where I am trying to utilize 4 CPUs in my Java program. I wanted to do something like

int numP         


        

Answer 1

Will this guarantee that I will have one thread working per CPU?

If you have four tasks which need to be executed at the same time, you can expect them have a thread each. In the HotSpot JVM, it creates the Thread object which are proxies for the actual thread when you create the pool. When the actual threads are created, and how, does matter to you.

At the time that I create the threads, the system will not be busy, however some time afterwards it will be extremely busy. I thought that the OS will pick the least busy CPU to create the threads, but how does it work if none of them are particularly busy at the time of creation?

Threads are created by the OS and it is added to the list of threads to schedule.

Also, the thread pool service is supposed to reuse threads, but if it sees there is more availability on another CPU, will it kill the thread and spawn a new one there?

Java has no say in the matter. The OS decides. It doesn't kill and restart threads.

Threads are not tied to CPUs in the way you suggest. The OS passes threads between CPUs based on which one threads need to run and which CPUs are free.

Answer 2

no it won't guarantee anything about where the threads run

in fact the OS thread scheduler is free to migrate threads around cores as it sees fit (so one line you could be on core 0 and the next on core 4)

you could set the affinity of threads but this is not available in java directly (AFAIK)

Answer 3

"if it sees there is more availability on another CPU, will it kill the thread and spawn a new one there?"

There is no need to kill and spawn another one to employ available CPU. Threads are memory objects that are not bound to particular CPU, and can float around from one CPU to another. Thread execution is a loop like this:

• Thread.start() puts the thread into the processor queue
• when there is available processor, scheduler takes the first thread in the processor queue an puts on the processor
• when the thread blocks on an occupied lock, or is waiting for the end of an I/O operation, it is taken off the processor and is put in the corresponding queue. When the lock is freed, or I/O operation finishes, the thread is moved from that queue back to the processor queue.
• when the thread works too long without blocking (o/s dependant time, say, 50 ms), an interrupt happens, and the scheduler looks if there are threads in the processor queue. If there are, current thread is taken off the processor and put at the end of the processor queue, and the first thread in the queue it put on the processor. This way the long running thread lets other threads to execute too.

As a result, threads often change their state but this is transparent to programmer. The whole idea of threads is that thread is a model of a processor, more convenient than real processor. Use that model and don't worry about mapping threads on processors, until you really need to.