3

I'm trying to understand Java internals about their scheduling and thread affinity.

The question is:

given an infinite loop, running on a thread as such in a multicore environment (e.g. 8):

while(true) Thread.sleep(1000);

  1. Will this operation always run on the same physical thread or not?

  2. Is there some kind of affinity?

  3. If it doesn't always run on the same CPU, how does the JVM decide to actually switch the execution to a new CPU?

  4. Any way to verify this behavior?

user207421
  • 305,947
  • 44
  • 307
  • 483
M4rk
  • 2,172
  • 5
  • 36
  • 70
  • "Will this operation always run on the same physical thread or not?" Well, during the sleep, the thread will not occupy any physical core, so it'll arguably almost never run. – that other guy Jan 31 '20 at 22:56
  • The sleep doesn't run at all, but the rest of the loop code does. The operating system is very likely to reconsider which core it runs in when each sleep ends. – user207421 Jan 31 '20 at 23:12

3 Answers3

6

The JVM (thankfully) is blissfully not responsible for scheduling thread times, because Java threads are isomorphic (that means 1:1) to native threads. Thus the operating system schedules when a Java thread runs, and the operating system manages thread affinity (and you must use native code if you wish to influence it in anyway). There is at least one library that provides such a mechanism, but I have never used it.

I say thankfully, because long ago, the JVM used green threads and managed them cooperatively. And it was a lot slower with regards to multiple cpus/cores.

Elliott Frisch
  • 198,278
  • 20
  • 158
  • 249
2

Will this operation always run on the same physical thread or not?

No. The physical thread will do other work while the logical thread is sleeping. It would take a coincidence for it to make sense to reschedule the logical thread on the same physical thread.

Is there some kind of affinity?

Not usually. This thread is almost never executing, so such an affinity would serve no purpose. You might see some useful affinity if a thread is spending more time executing because returning it to the same physical core might keep the caches warm. But that would make no sense for a thread that's constantly yielding its time slices.

If it doesn't always run on the same CPU, how does the JVM decide to actually switch the execution to a new CPU?

The JVM doesn't. That's the scheduler's job.

Any way to verify this behavior?

It's not clear what it is you want to verify. What's the issue?

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
0

Thread.sleep() causes the thread to leave physical processor and get into the queue to the system timer. When the timer awakes the thread, it puts it into the queue to processors. Then it resumes execution on the first available processor.

Some operating systems allow to bind particular thread to a particular processor, but this will be done only as a result of explicit tuning. If you did not do such a tuning, then you may assume the processor is chosen randomly.

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