Java Thread Scheduling

Question

My notes say that there are two main categories of thread scheduling algorithms, preemptive and time sharing. I'd like to clear up exactly how these work in Java.

As I understand (and PLEASE correct me if I'm even slightly wrong!) preemptive allows a higher priority thread to take over the CPU from a lower priority thread when it enters the runnable state. Will it monopolize the CPU until an even higher priority thread comes along, or will it simply consume most of the CPU time, but lower priority threads will also get a chance to run? I'm assuming here that there are no calls to methods that will give up the CPU like yield() or sleep().

In time sharing, does a higher priority thread get a greater share of CPU time?

I'm guessing my explanation (well the question I've posed) for preemptive cannot be right as then it just seems the same as time sharing! But I'd like to be sure of the details.

And I suppose, how is this all implemented? Does the JVM or the OS schedule threads, or is that JVM implementation dependent?

Answer 1

First, I suspect that your notes are incorrect, and should be non-preemptive versus time-sharing (which is also known as preemptive). At least, that's how the breakdown went when I took an OS class several decades ago, and I doubt that it's changed.

In a non-preemptive thread (/process) model, each thread (/process) is granted sole use of the CPU until it explicitly relinquishes it. This is the model that you find in single-user operating systems such as the original Windows or Macintosh (as well as a bunch of minicomputer systems that predated them). A running process could explicitly yield() its control of the processor, allowing another thread/process to run. Of course, there are many caveats to that, particularly regarding interrupt handling, but I'll leave the description there.

In a preemptive, aka timesharing model, the operating system may force a thread/process to yield the CPU (ie, "preempt" it). This can happen at any number of places, but in the simplest case the OS is called on every tick of a clock, and decides which process should get the CPU for the next tick of the clock. Again simplifying, the process with the highest priority gets to run; if there are multiple processes at the same priority, a least-recently-run algorithm generally decides.

But, regardless, for all modern Java implementations, it's the OS that decides when (and where) a thread should run, not the JVM.

Answer 2

Not a thread expert but letting a thread run indefinitely can lead to starvation. You still give lower priority ones some time. I believe time sharing gives all threads basically the same amount. These notes may help a little bit.

From said notes:

Non-preemptive Scheduling: The current process releases the CPU either by terminating or by switching to the waiting state. (Used in MS Windows family)

• Pros:
  • Decreases turnaround time
  • Does not require special HW (e.g., timer)
• Cons
  • Limited choice of scheduling algorithm

Preemptive Scheduling: The current process needs to involuntarily release the CPU when a more important process is inserted into the ready queue or once an allocated CPU time has elapsed. (Used in Unix and Unix-like systems)

• Pros:
  • No limitation on the choice of scheduling algorithm
• Cons:
  • Additional overheads (e.g., more frequent context switching, HW timer, coordinated access to data, etc.)

Answer 3

Actually, a thread is an abstract concept. It is just an atomic process which should be executed. By atomic, I mean a process which, if you stop it (e.g. because it is too long and you want to execute another one) you need to store its current state and restore it before to continue the execution of the process. Now, what is in the process depends on what you want it to be. In C for instance, a language which were designed to build OSs if I remember well, a process is basically a program. This program can ask to the system to run other programs, or to fork itself to run a clone (by using the fork() function). Whether it is a different program or a clone, it is anyway a different process, which should be executed atomically. In C, a thread is a program. In Java, a thread is a class extending Thread. In C, you start a thread/program by executing its main() function, in Java you run a thread/class by executing its run() method. That is for the thread concept alone. It is just a generic name for the program or the Thread instance which is executed.

Nowaday, computers need to execute many stuff in parallel. It leads to manage several threads at the same time. Here comes the thread pool: it is a list of threads to execute. Nothing more. A simple list. But with that, you have the scheduler: you have a given number of "processors", and you need to decide which threads to execute on them, but you cannot execute more threads than you have "processors". The scheduler strategy should be designed to save as much time as possible, and this depends on the content and the dependencies of the threads. Different strategies can be used, like a balanced execution time, round robin, priorities, etc.

I put "processors" in quotes because I mean here "computing units". It can be the physical processor of the computer, or CPU, which nowaday has between 2 and 8 cores usually (meaning it can run 2-8 threads at the same time), and execute CPU instructions (typically RISC). It can be the processors of the graphic card, or GPU, which has several dozens or hundreds of cores, but use a different set of instructions. Iit can also be the processor from the Java Virtual Machine or JVM, which can run a single thread only and use its own set of instructions (bytecode). The main difference between the JVM and the two previous ones is that the CPU and GPU interact directly with the hardware, without intermediaries, while the JVM translate its own bytecode into RISC instructions and ask to the CPU to execute them.

The CPU uses its own scheduler to execute its threads (bloc of RISC instructions, not only one). Let call it a "system thread". But when you program in Java, your execution environment is not the system, it is the JVM, which provides you an abstraction of the system (this is how you can run a Java program on any machine without caring about the system underneath). This means that you are not allowed to communicate with the system directly, so Java provides you a way to deal with threads at its own level, allowing you to create the threads (new Thread()) and provide them to a scheduler (SwingUtilities, Executors, etc.). How your Java threads are translated into system threads, and how your Java scheduler is used to replace the system scheduler, is the job of the JVM.

So when you speak about a thread in Java, you don't speak about a thread at the system level. This is the JVM which will interact with the system in order for you to have a similar behaviour. But your Java thread are not managed by the CPU, thus your ability to ask for a specific scheduling strategy, independently of the scheduling strategy of the CPU.

How is Thread scheduling in Java done?. Available from: https://www.researchgate.net/post/How_is_Thread_scheduling_in_Java_done [accessed May 22, 2017].

Answer 4

This answer is found on another source ..im pretty confused.but posting anyway. I am not actually aware of the Java specification or how JVMs are actually implemented. But, here is my reasoning about this. Some people mentioned that the JVM could run just a single thread on the operating system and do its own scheduling inside the JVM. To me, this does not make sense because compared to other software which would be using several real OS-level threads your Java software would have much worse performance (in a simplified view every OS thread would get the same amount of time, and several Java threads would have to share the time of a single OS thread).

So, it is more likely that the JVM will launch an OS-level thread for each thread you create in Java. Then it is up to the operating system to schedule the threads. Specifying a thread priority in Java can be mapped differently to OS threads depending on the implementation of the JVM and the capabilities of the operating system. For Linux, for example, priorities are combined with round robin scheduling. Mostly it varies with the amount of time that is scheduled for a thread. Time slices should not become of zero length which then prevents total starvation of a thread. There is, however, the possibility to use realtime threads in Linux (probably not accessible from Java) to make the OS totally unresponsive.

I guess the Java specification mentions preemptive thread scheduling because there are only two major ways to do multithreading: there is preemptive scheduling and cooperative multithreading. For preemptive multithreading you need the support of the hardware and the operating system. Cooperative multithreading, on the other hand, means that you will have to call a function inside your source code to actively switch between threads. If your own source code does not call this function, in cooperative multithreading no other thread can run.

As a response to one of the answers you also asked about thread pools. Usually, thread pools are used in the following way: You have a pool with a fixed number of threads. This might be one thread per core for example. Upon creation of the thread pool all threads don't have any work to do. Now, you are able to assign tasks to the pool. The pool will then use its threads to eventually provide a result for every task. The advantage of this is that you can throw in a lot more tasks into the pool than you have actual threads available. This is an easy way to not overload your system with too many threads at once (by using one thread per task at the same time). To learn more about this you can look for "futures".

How is Thread scheduling in Java done?. Available from: https://www.researchgate.net/post/How_is_Thread_scheduling_in_Java_done [accessed May 22, 2017].