Multithreading and Multiplexing - An Introduction to Network Programming with Java - page 48

Though the use of threads cannot guarantee that a server will not crash, it greatly
reduces the likelihood of it happening by signifi cantly increasing the number of
client programs that can be handled concurrently.

3.1 Thread Basics

A thread is a fl ow of control through a program. Unlike a process, a thread does not
have a separate allocation of memory, but shares memory with other threads created
by the same application. This means that servers using threads do not exhaust their
supply of available memory and collapse under the weight of excessive demand
from clients, as they were prone to do when creating many separate processes. In
addition, the threads created by an application can share global variables, which is
often highly desirable. This does not prevent each thread from having its own local
variables, of course, since it will still have its own stack for such variables.
Though it has been entirely transparent to us and we have had to make no explicit
programming allowance for it, we have already been making use of threads in our
Java programming. In fact, we cannot avoid using threads in Java, since each pro-
gram will have at least one thread that is launched automatically by our machine's
JVM when that program is executed. Such a thread is created when main is started
and 'killed' when main terminates. If we wish to make use of further threads, in
order to 'offl oad' processing tasks onto them, then we have to program such threads
explicitly. Using more than one thread in this way is called multithreading .
Of course, unless we have a multiprocessor system, it is not possible to have
more than one task being executed simultaneously. The operating system, then,
must have some strategy for determining which thread is to be given use of the pro-
cessor at any given time. There are two major factors…

￿ Thread priority (1-10, in increasing order of importance) in Java

￿ Whether scheduling is pre-emptive or cooperative .

A pre-emptive scheduler will determine when a thread has had its fair share of
CPU time (possibly via simple time allocation) and will then pause it (temporarily).
A cooperative scheduler, on the other hand, will wait for the running thread to
pause itself before giving control of the CPU to another thread. A JVM using coop-
erative scheduling is thus much more susceptible to thread starvation (from unco-
operative, high-priority threads 'hogging' the processor).
On PCs, threads with the same priority are each given an equal time-slice or time
quantum for execution on the processor. When the quantum expires, the fi rst thread
is suspended and the next thread in the queue is given the processor, and so on. If
some threads require more urgent attention than others, then they may be assigned
higher priorities (allowing pre-emption to occur). Under the Solaris operating sys-
tem, a thread runs either to completion or until another higher-priority thread becomes
ready. If the latter occurs fi rst, then the second thread pre-empts the fi rst and is given
control of the processor. For threads with the same priority, time-slicing is used, so
that a thread does not have to wait for another thread with the same priority to end.