Thread scheduling algorithm in java

[radha gogia]

what is the thread scheduling algo implemented for the execution of threads in java,in the docs it is mentioned that JVM uses preemptive and priority scheduling but as far as I know the threads are to be excuted by the Operating System,then it should I guess totally depend on the scheduling algo used by the OS for execution of the threads ,then why is it said that JVM uses premmptive and priority scheduling .

Obviously it is clear that the JVM will surely schedule the threads but the task of execution depends entirely on the OS, also I found somewhere that JVM overrides the scheduling algorithm of OS,so what is the case with it?

[Henry Wong]

First, welcome to the ranch.

As you mentioned, for all modern JVMs, the actual scheduling of the threads are forwarded to the underlying OS -- so it is the operating system that determines scheduling.

The API does allow you to specify a priority, which is then forwarded to the OS. And of course, for some OSes, it may not map very well. For example, Windows has less priority levels, so some adjacent priority are really the same priority when scheduling.

As for preemptive, the specification mentions that, but it isn't that strict. I believe all modern OSes are preemptive, so it isn't an issue, but I do recall that with an older OS, this may be handled by a timer (so, it is not a violation if it is not completely preemptive).

Henry

[radha gogia]

But sir if the JVM is depending on the scheduling algo of the OS ,and if the OS is using round-robin algo which normally these days modern OS are using then I guess it would be a combination of both the priority and the round-robin algo ,but then the problem which I foresee is that if context switching would occur because of round-robin where each time slice is used then it would imply that in a particular thread some part would be executed and after sometime again control would come back to it ,and I guess it never happens while execution of threads in java ,so I guess round-robin algo is not used .

Then Sir, what will happen because actually the execution will occur on the basis of scheduling algo used by the OS ,then if it uses round-robin then how will actually the complete execution of thread occur?

[Henry Wong]

radha gogia wrote:then the problem which I foresee is that if context switching would occur because of round-robin where each time slice is used then it would imply that in a particular thread some part would be executed and after sometime again control would come back to it ,and I guess it never happens while execution of threads in java ,so I guess round-robin algo is not used .

Not sure of the issue here. Or more specifically, not sure how you conclude that the native schedulling can't be used. Can you elaborate how it "never happens"?

Henry

[radha gogia]

Sir,actually I have major confusion that if the JVM depends on the OS scheduling algo and if the OS uses round-robin algo ,and in this algo we have time slicing for execution of threads ,then at some part of time some portion of thread would execute and after some time its other part would execute ,because of the time slice allotted .so the fact that I used the term "it never happens' , I meant to say that in java threads are executed in its entire manner and after the thread is executed in its entire manner then the other high priority thread would be executed .

So confusion here only arises that if OS is using round-robin then will the threads be executed in that manner only or only when the resources are less then only the threads would be scheduled in round-robin manner.

Hence,if the threads are not implemented using round-robin then that means JVM must have overriden the scheduling algo of OS ,sir please correct if me I said anything wrong there are still many confusions .

[Henry Wong]

radha gogia wrote:so the fact that I used the term "it never happens' , I meant to say that in java threads are executed in its entire manner and after the thread is executed in its entire manner then the other high priority thread would be executed .

Yeah. You probably need to clarify a bit more. There is no such guarantee that a Java thread must run to completion without taking a context switch.

Can you show us an example of this?

Henry

[radha gogia]

Sir,I meant to say that in normal cases threads run to completion ,so is it that if there is an occurrence of context-switch within your thread execution then it is because of round-robin algo implementation occuring within the algo,because it divides each thread into time slice,then again confusion arises that are the time slots always divided or they are divided only when the resources are less.

[Henry Wong]

radha gogia wrote:Sir,I meant to say that in normal cases threads run to completion ,so is it that if there is an occurrence of context-switch within your thread execution then ...

Question. When a context switch happens, how do you even know that it is happening? Depending on the operating systems, it can happen more than a dozen times a second -- How do you even tell it is happening? Do you have a tool for it? Or are you not noticing any hiccups, and is assuming that it is not happening?

radha gogia wrote: ... then it is because of round-robin algo implementation occuring within the algo,because it divides each thread into time slice,then again confusion arises that are the time slots always divided or they are divided only when the resources are less.

Assuming that the operating system does round robin scheduling, it can also do (and often does) many other things simultaneously, so this question can't be answered easily. And even if it can, it will be operating system specific (unless you are running an old JVM, that doesn't dispatch to the native threading system). Some possibilities for an operation system to do a context switch are ...

1. The currently running thread is no longer in a runnable state. Some examples are writing to a disk, writing to a network socket, synchronizing on an object, or calling wait() on an object.

2. A higher priority thread has entered the runnable state (ie. no longer blocked), and will preempt the currently running thread.

3. A thread priority changed due to priority inheritance (which is generally caused by a high priority thread trying to enter the runnable state, but can't due to a low priority thread holding it's lock), and that causes preempting the currently running thread.

4. A thread priority (effective) causes the preempting of the currently running thread. The best example of this is Windows as it has mechanisms to prevent thread starvation.

5. And of course, the round robin algorithms that you mentioned, which is how the OS shares runnable similar priority threads on limited CPU resources.

And ... as mentioned, the Java specification is very relaxed on this. The OS can do all of this and remain in compliance. This is so that the JVM is allow to have the native threading system do the scheduling, regardless of the OS. This also means that a Java programmer should never be dependent on the scheduling, as it may be different on a different OS.

Henry