Page 106 - DCAP103_Principle of operating system

Unit 3: Process Management-II

machine implementations for those operating systems must perform the necessary thread Notes
scheduling on their own.
Our first example, where the threads all complete at about the same time, is executed on a
standard operating system (Solaris) where the thread scheduling is handled by the operating
system. Our second example, where the threads run sequentially, is from a system where the
Java virtual machine itself handles the thread scheduling. Both implementations are valid Java
virtual machines.

3.7.2 The Scheduling Process

Let us examine how the scheduling process works in a little more detail. At a conceptual level,
every thread in the Java virtual machine can be in one of four states:

3.7.2.1 Initial

A thread object is in the initial state from the period when it is created (that is, when its constructor
is called) until the start( )method of the thread object is called.

3.7.2.2 Runnable

A thread is in the runnable state once its start( ) method has been called. A thread leaves the
runnable state in various ways, but the runnable state can be thought of as a default state: if a
thread is not in any other state, it is in the runnable state. A thread that is in the runnable state
may not actually be running; it may be waiting for a CPU. A thread that is running on a CPU
is called a currently running thread.

3.7.2.3 Blocked
A thread that is blocked is one that cannot be run because it is waiting for some specific event to
occur. Threads block for many reasons: they attempt to read data (e.g. from a socket) when no data is
available; they execute a thread-blocking method (e.g. the sleep( ), wait( ), or join( ) methods);
or they attempt to acquire a synchronization lock that another thread already holds. We have
seen APIs that also block, but internally those methods are all executing the wait( ) method.

3.7.2.4 Exiting

A thread is in the exiting state once its run( ) method returns (or its deprecated stop( ) method
has been called).

The basic process of thread scheduling is essentially the same whether it is performed by the
Java virtual machine or the underlying operating system. Our intent here is to provide an
illustration of how thread scheduling works, not to provide a blueprint of how any particular
thread scheduler is actually implemented.

We can conceive that a thread scheduler keeps track of all the threads on which it operates
by using linked lists; every thread is on a list that represents the state of the thread. A Java
thread can have one of 11 priorities, so we conceive of 14 linked lists: one for all threads
in the initial state, one for all threads in the blocked state, one for all threads in the exiting
state, and one for each priority level. The list of threads at a given priority level represents
only those threads that are currently in the runnable state: a thread in the runnable state at
priority 7 is placed on the priority 7 list, but when the thread blocks, it moves to the blocked
linked list. We’re speaking here of having 11 priorities, but that number is a Java abstraction:

LOVELY PROFESSIONAL UNIVERSITY 99