In our Thread methods overview, we mentioned the
setPriority() and getPriority() methods. The essential idea is that
we call setPriority() on a thread, passing in an integer representing its priority.
The number should lie in the range of two constants MIN_PRIORITY and
MAX_PRIORITY defined on Thread, and will typically reference
NORM_PRIORITY, the default priority of a thread if we don't set it to anything else.
For example, to give a thread a priority that is
"half way between normal and maximum", we could call:
thr.setPriority((Thread.MAX_PRIORITY - Thread.NORM_PRIORITY) / 2);
Problems with thread priorities
The notion that some threads should have
a higher "priority" than others is an intuitive idea. However, there are a couple of caveats with
thread priorities that we need to beware of:
depending on your OS and VM version, Thread.setPriority() may actually
do nothing at all (see below for details);
what thread priorities mean to the thread scheduler
differs from scheduler to scheduler, and may not be what you intuitively presume; in particular:
Priority may not indicate "share of the CPU".
(As we'll see below, it turns out that "priority" is more or less an indication of CPU distribution on
UNIX systems, but not under Windows.)
thread priorities are usually a combination of "global" and "local" priority
settings, and Java's setPriority() method typically works only on the local
priority— in other words, you can't set priorities across the entire range possible
(this is actually a form of protection— you generally don't want, say, the mouse pointer thread
or a thread handling audio data to be preempted by some random user thread);
the number of distinct priorities available differs from system to system, but Java
defines 10 (numbered 1-10 inclusive), so you could end up with threads that have different
priorities under one OS, but the same priority (and hence unexpected behaviour) on another;
a system could (and typically does) add some OS-specific behaviour to threads depending
on their priority (e.g. "only give a quantum boost if the priority is below X")— so again, part of
what "priority" means differs from system to system;
most operating systems' thread schedulers actually perform temporary manipulations
to thread priorities at strategic points (e.g. when a thread receives an event or I/O it was waiting for),
and often "the OS knows best"; trying to manually
manipulate priorities could just interfere with this system;
your application doesn't generally know what threads are running in other processes,
so the effect on the overall system of changing the priority of a thread may be hard to predict.
So you might find, for example, that your low-priority thread designed to "run sporadically in the background"
hardly runs at all due to a virus dection program running at a slightly higher (but still 'lower-than-normal')
priority, and that
the performance unpredictably varies depending on which antivirus program your customer is using.
Of course, effects like these will always happen to some extent or other on
Next: thread priority in more detail
Having sufficiently vilified thread priorities, on the next page
we'll look in more detail at what Java thread priority means
on different systems.