3

Let's say I have 2 threads a and b running inside the same process. The processor runs a few instructions from a, a few from b and so on until it reaches a line of code like this: Thread.sleep(1000).

The problem is that I don't really understand what the processor will do next. I suspect these 2 scenerios:

1)

  • Thread a starts to sleep for 1000 miliseconds
  • meanwhile b is running
  • the 1000 milisecond interval is over so:
    • if the proccessor still runs code from Thread b
      • then wait until it finishes
      • and run more code from Thread a
    • else
      • run more code from Thread a

2)

  • Thread a starts to sleep for 1000 miliseconds
  • meanwhile b is running

  • the 1000 milisecond interval is over so:

    • if the proccessor still runs code from Thread b

      • STOP THREAD B. since Thread a has higher priority and it's code must be run IMMEDIATELY after the 1000 miliseconds interval it's finished
      • and run more code from Thread a
      • THEN run code from Thread B from where we left.
    • else
      • run more code from Thread a

Which one resembles what's actually going on behind the scenes? If both are wrong then please indicate me the correct answer.

duffymo
  • 305,152
  • 44
  • 369
  • 561
Dragos C.
  • 621
  • 2
  • 7
  • 15

2 Answers2

4

A lot of factors come into play, so it's tough to provide an absolute answer for your question.

But based on the available options you have given, #2 will be closest.

A different thread is invoked to run in case one of the following events occur:

....
A thread with a higher priority than the thread currently running enters the Runnable state. The lower priority thread is preempted and the higher priority thread is scheduled to run.

Here's the source.

Jops
  • 22,535
  • 13
  • 46
  • 63
  • 1
    This ultimately does not depend on the JVM, [but, **again**, on the underlying OS scheduler](http://javaho.wordpress.com/2011/01/10/jvm-thread-scheduling-is-platform-dependent/). – m0skit0 Mar 31 '13 at 15:14
  • +1. yes. If a thread that was waiting on I/O has to wait until some other, possibly lower-priority, thread to 'finish', there would be little reason to use a preemptive multitasking OS at all. – Martin James Mar 31 '13 at 16:58
  • @MartinJames And again, it's up to the OS scheduler (see link in my previous comment). You're right if the OS has a fixed priority pre-emptive scheduler, but this might not be case. – m0skit0 Mar 31 '13 at 20:10
  • @m0skit0 any other approach is not sane. – Martin James Mar 31 '13 at 21:17
  • @MartinJames not all OSs are for PCs. – m0skit0 Mar 31 '13 at 23:07
3

It's the OS that schedules threads and processes, not processor(s). How it does it depends on the OS scheduler, and it varies from an OS to another.

Even if the JVM does have a thread scheduler, the behavior ultimately does not depend on the JVM, but on the underlying OS scheduler.

See this for how the 2.6 Linux scheduler works.

Community
  • 1
  • 1
m0skit0
  • 25,268
  • 11
  • 79
  • 127
  • Still depends on scheduler policy. – m0skit0 Mar 31 '13 at 14:44
  • 2
    @m0skit0 Does the same thing apply for when we are using non-blocking I/O and we read from the filesystem, provide a callback for when the reading is done( the callback might contain code to print that content to the screen or something else) and the we have more code. In this case, when will the callback be run? When we finish running the rest of the code or immediately after the content was read from the filesystem... (the question is similar to the first one, just that instead of sleeping, the problem comes from non-blocking I/O) – Dragos C. Mar 31 '13 at 14:53
  • Again, this depends on the scheduler policy. If you specify one scheduler policy, we can answer way more accurately. – m0skit0 Mar 31 '13 at 15:05