17

C H A P T E R

Threads and Locks

And oft times in the most forbidding den

Of solitude, with love of science strong,

How patiently the yoke of thought they bear;

How subtly glide its finest threads along!

 William Wordsworth,

 Monks and Schoolmen

,

in

Ecclesiastical Sonnets

 (1822)

W

HILE most of the discussion in the preceding chapters is concerned only with

the behavior of Java code as executed a single statement or expression at a time,

that is, by a single

thread

, each Java Virtual Machine can support many threads of

execution at once. These threads independently execute Java code that operates on

Java values and objects residing in a shared main memory. Threads may be sup 

ported by having many hardware processors, by time slicing a single hardware

processor, or by time slicing many hardware processors.

Java supports the coding of programs that, though concurrent, still exhibit

deterministic behavior, by providing mechanisms for

synchronizing

 the concur 

rent activity of threads. To synchronize threads, Java uses

monitors

, which are a

high level mechanism for allowing only one thread at a time to execute a region of

code protected by the monitor. The behavior of monitors is explained in terms of

locks

; there is a lock associated with each object.

The

synchronized

 statement ( 14.17) performs two special actions relevant

only to multithreaded operation: (1) after computing a reference to an object but

before executing its body, it

locks

 a lock associated with the object, and (2) after

execution of the body has completed, either normally or abruptly, it

unlocks

 that

same lock. As a convenience, a method may be declared

synchronized

; such a

method behaves as if its body were contained in a

synchronized

 statement.

The methods

wait

 ( 20.1.6,  20.1.7,  20.1.8),

notify

 ( 20.1.9), and

notifyAll

( 20.1.10) of class

Object

 support an efficient transfer of control

from one thread to another. Rather than simply  spinning  (repeatedly locking and

unlocking an object to see whether some internal state has changed), which

399