A bit of reflection will show the reader that two of the methods can be executed entirely in user
space, with the thread-level context switch requiring about 10 ms on a 167-MHz UltraSPARC.
Preemption, however, is a bit more involved and requires a system call to execute (see
In actual practice, you, the programmer, will spend very little time thinking about issues of
scheduling. When a thread needs a common resource, it uses a lock. If it doesn't get the lock, it
blocks, and another thread runs. Sooner or later the owner will release the lock and the first thread
will become runnable again.
Priority Levels
The scheduler for unbound threads has a simple algorithm for deciding which thread to run. Each
thread has an associated priority number. The runnable threads with the highest priorities get to
run. These priorities are not adjusted by the JVM. The only way they change is if the programmer
writes an explicit call to do so [thread.setPriority()]. This priority is an integer in Java,
with value between MIN_PRIORITY (1) and MAX_PRIORITY (10).
There are all sorts of details and exceptions related to Java priorities. On Windows NT there are
only seven priority levels to which the ten Java priority levels must be mapped. Native POSIX
libraries that use unbound threads don't necessarily propagate those priority numbers up to the
LWPs. Java does not guarantee any behavior related to priority levels.
By default, Java threads will start with NORM_PRIORITY (5). You can change that value as you
please. We don't give you any advice on how to choose the value, as we find that we don't use it
much ourselves. You probably won't, either. We are not aware of any significant programs that set
priority levels!
Nonetheless, there are plenty of programmers who love priorities. They carefully raise and lower
levels to meet some criteria, expecting to control the program's behavior closely. They are almost
certainly fooling themselves. Don't use priorities.
Scheduling States
The natural consequence of the discussion above on scheduling is the existence of four scheduling
states for threads. (The astute reader who has already figured this all out may skip this section.)
A thread may be in one of the following states:
Active:
It is on an LWP.[7]
[7]
Whether or not the LWP is on a CPU is irrelevant.
Runnable:
It is ready to run, but there just aren't enough LWPs for it to get one. It will remain here until an
active thread loses its LWP or until a new LWP is created.
Sleeping:
It is waiting for a synchronization variable.
Search WWH :
