11

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 numProcessors = Runtime.getRuntime().availableProcessors();
ExecutorService e = Executors.newFixedThreadPool(numProcessors);

Will this guarantee that I will have one thread working per CPU? 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?

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?

3 Answers3

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)

ratchet freak
  • 47,288
  • 5
  • 68
  • 106
2

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.

randers
  • 5,031
  • 5
  • 37
  • 64
Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • My concern is really that the OS is going to instantiate them all on the same CPU and then because it reuses threads, that it will keep them there, even if it comes to a point where that CPU is pinned and the other 3 are free. Is this possible? –  Dec 13 '12 at 18:37
  • You can force the OS to do that, but by default it will give each cpu, the next free thread which can run. – Peter Lawrey Dec 13 '12 at 18:39
  • I see, thanks for the update. If the OS is passing the threads across CPUs then I think that answers my question. What is the best way to monitor this on UNIX? If I use the `top` function will I see more than one Java proc running? –  Dec 13 '12 at 18:49
  • If you press `1` in top it will show you all the cpus. If you run just one busy thread you will see it move around even though there is no practical reason to do so. In fact it's annoying if you are trying to write a low latency application because every time it moves, the thread incurs a delay and a slow down. – Peter Lawrey Dec 13 '12 at 18:54
  • @Marianna... what is top function? how does it help me to look for my threads nature across available CPU's? And what is pressing 1 in top? Sorry, I am not following the last to return comments both dated Dec 13'12 AT 18:49 and Dec 10'12 at 18:54. – MKod Dec 05 '14 at 06:51
  • @MKod top is a command line tool on Unix. When you run top you can change the display by pressing the `1` key on your keyboard. I suggest you run it and it's function will be clearer. – Peter Lawrey Dec 05 '14 at 14:54
  • @PeterLawrey Since I am new to multicore concurrency on Java, I too am interested in making sure that when I create some threads they are not pegged to one CPU. I guess the JVM will spread them around based on the OS scheduler. In a separate issue I am also interested in dedicating a core to its own CPU and have that CPU only run that thread. – Xofo Sep 28 '15 at 17:54
  • @xofo the OS controls where threads are run. All the JVM does is make the right system calls. To dedicate a cpu or core to a thread you can use thread affinity to an isolated cpu on linux. Google for Java Thread Affinity. – Peter Lawrey Sep 29 '15 at 11:01
  • @PeterLawrey - Are there some good white papers / examples / articles on this. Thanks for your input. – Xofo Sep 30 '15 at 21:55
  • @Xofo any papers on how threads work in Windows or Linux would apply. – Peter Lawrey Oct 02 '15 at 11:45
1

"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.

Alexei Kaigorodov
  • 13,189
  • 1
  • 21
  • 38