For "Alfonse,
Wait
Here My Signal!"
Stephen J. Hartley Computer Science and Information Systems Richard Stockton College, Pomona, NJ 08240-0195 +l 609 652 4968 [e-mail]
Abstract
At first glance, Java monitors appear easy to use. However, a deeper analysis reveals that they are surprisingly tricky, suffer from subtle race conditions, and are actually a low-level synchronization tool in stark contrast to the reputation Java has as a modern well-engineered language. The programmer is responsible for building safe and robust synchronization structures from Java monitors.
1 Java Is Multithreaded
periodically, allowing one thread to tell another thread to stop itself or return allocated resources if it is not in the middle of some critical operation. A thread should check its interrupt flag before or after such operations and take appropriate action when interrupted.
2 Object Locks
A new thread in a Java program is created [2] by subclassing the Thread class and overriding the run method; or by implementing the Runnable interface, which means providing an implementation of the run method. Once started, a Java thread is in one of several states: runnable, in the runnable or ready set; mnning on the CPU; dead, when its run method completes; blocked, waiting for an event to occur such as completion of an IO, joining with another thread, returning from a sleep (ms> method call, acquiring an object's lock, or a monitor signal from another thread; suspended until resumed. Java threads have a user-settable priority. The Java virtual machine (JVM) scheduler usually ensures that the highest priority thread is running on the CPU, preempting the currently running thread when necessary, but this is not guaranteed by The Java Language Specification [4, page 4151. Time slicing (round robin scheduling) of threads by the JVM is optional: Windows 95/NT does, Solaris does not. A Java thread is interrupted when its interrupt method is called by another thread. This call sets a flag in the interrupted thread that the latter can check
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed tar profit or CommerCial edvanend that copies bear this notice and the full citation on the first page. 70 copy otherwise, to republish, to post on Servers Or to redistribute to lists, requires prior specific permisslon and/or a fee. SIGCSE'BB 3/99 New Orleans, LA, USA 0 1999 ACM l-581 13-085~6/99/0003...$5.00
Every Java object has a lock. A thread executing a synchronized statement must acquire the specified object's lock, blocking if the object is already locked, before executing the statement. It acts like a binary semaphore with initial value one and solves the mutual exclusion critical section problem: Object obj = new Object (> ; // methods share ... synchronized (obj) ( // in several methods section . . . // any code, e.g., critical 3
The Java Language Specification does not guarantee that the thread waiting the longest to lock an object is the next thread to obtain the lock when the object is unlocked. The construct
synchronized
3
type qethod(. . . . body of method
. .> C
is an abbreviation for
type method(. . .I <
synchronized
3
(this)
(
. . . body of method
tage
that is, the entire body of the instance method is a synchronized statement on the object (referenced with this) the method is in.
3 Java Monitors
In addition to a lock, every Java object has methods wait, notify, and notifyAll. A Java monitor has the following structure or pattern.
58
class Monitor extends . . . { private . . . // data fields: monitor state Monitor ( . . .) C...) // constructor synchronized type methodic...) { ... notifyAll0; // if state altered while (! condition) try ( wait0 ; ) catch (InterruptedException e) {) ... notifyAll(); // if state altered
several threads waiting on a specific condition with not if y. It is safer to use not if yAl1 to wake up all waiting threads and let them recheck their waiting conditions. However, this might be very inefficient and greatly increase overhead. In some situations, we can use not if y instead of not if yAl1 and if. . . wait 0 instead of while . . . wait 0. However, it is extremely tricky as we will see!
3
synchronized type method2 ( . . . ) throws InterruptedException ... notifyAll(); // if state altered while (! condition) wait0 ; ... notifyAll0; // if state altered (
A not if yAl1 needs to be done by a thread before a wait if any state variables that might affect other thread waiting conditions were altered by the thread after entering the monitor. This also applies when a thread leaves the monitor (returns from a monitor method call).
If a thread that is blocked inside a call to sleep, join, or wait is interrupted, then these methods clear the thread's interrupt flag and throw an InterruptedException instead of returning normally. Note that no exception is thrown if a thread is interrupted while blocked waiting to acquire a monitor's lock to execute a synchronized method. In contrast, InterruptedException is thrown by wait if a thread that has been notified is interrupted while blocked, waiting to reacquire the monitor lock. Ignoring Interrupt edExcept ion with catch block is acceptable in while (! condition) try ( catch (InterruptedException wait0 an empty
3 ... 3
Some important
l
things to note are the following.
The thread blocked the longest on a monitor synchronized method call is not guaranteed to be next thread to acquire the monitor lock when the monitor lock is released. The thread blocked the longest in a monitor wait method call is not guaranteed to be the one removed from the wait set when a not if y method call is made by some other thread in the monitor [4, page 4171. Since the signaling discipline is signal-and-continue [l], barging is possible [3]: a thread waiting for the monitor lock to execute a monitor synchronized method might get the lock before a signaled thread reacquires the lock, even if the not if y occurred earlier than the monitor method call. Thus, in most situations a thread should recheck its waiting condition when signaled while ( ! condition) ... notifyAll ;, . . . wait 0 ;
l
; 1 e) ( 3
l
as long as we are using notifyAl t if y. But it is not acceptable in if (!condition) try c waito; catch (InterruptedException
instead of no-
3 e) ( 3
rather than unconditionally tering the monitor. if (! condition) ... notify0 ;
l
continuing
after reen4
because a thread interrupted out of its wait then reenters the monitor without being notified. However, it is more desirable in either case to have the containing method throw the exception back to the method's caller so the latter knows an interrupt occurred, as in method2 above. Sequence of Examples
. . . wait0
;
Each monitor object has a single nameless anonymous condition variable. We cannot signal one of
Suppose we want to implement a counting, semaphore with a Java monitor. Semaphores have two operations. P: If the semaphore's value is 0 then block, else decrement the value. V: If one or more threads are blocked inside P then unblock one, else increment the semaphore's value.
59
We want this Java monitor to have the following desirable properties. Safety: The number of successful P operations does not exceed the initial value of the semaphore plus the number of completed V operations, that is, no more Ps complete than possible. Liweness: The number of successful P operations equals the smaller of (a) the number of attempted P operations, and (b) the semaphore initial value plus the number of completed V operations. In other words, as many Ps complete as possible. No barging: If one or more threads are blocked inside P in wait and a thread calls V, then the P of one of the waiting threads succeeds. If some other thread calls P just after the call to V completes, it blocks inside P rather than succeeding, that is, no "sneaking in and stealing" the semaphore value from a notified thread. Single signals: The V operation is implemented with notify0 rather than notifyAll since a V releases at most one thread blocked inside P. Passed back exceptions: If a thread blocked inside P in wait is interrupted, the exception is thrown back to the calling thread. 4.1 First Attempt I
public
synchronized void P(> throws InterruptedException while (value == 0) wait 0 ; value--;
(
3 public synchronized void VO C if (value == 0) notify(); value++ ; 3 3 A subtle barging problem still exists. Suppose several threads are blocked inside P in wait 0 and some thread other does a V and notify0. One of the waiting threads is moved from the wait set to the (re)acquire monitor lock set. Now suppose several other threads barge in and call V before the notified thread reenters the monitor. No notifies are done. The net result is a counting semaphore with a positive value but several waiting threads, a liveness violation. We could fix this by using notifyAl 0 or by removing the if in front of the not if y0. But this is inefficient and introduces extra overhead. We also have a barging problem that results in starvation but not the safety error of the first attempt. A thread calling P can barge ahead of a notified thread, causing the notified thread to wait 0 again. The fix for this is to allow the semaphore value field to go negative, in which case its absolute value is the number of threads blocked inside P in wait 0. 4.3 Third Attempt (
public class CountingSemaphore private int value = 0; public ( if public CountingSemaphore(int (initial > 0) value
initial) = initial;
)
synchronized void P(> throws InterruptedException if (value == 0) wait 0 ; value-- ;
C
public class CountingSemaphore private int value = 0; public { if public CountingSemaphore(int (initial > 0) value
public synchronized void VO X if (value == 0) notifyo; value++ ; 3
initial) = initial;
)
synchronized void PO throws InterruptedException value-- ; if (value C 0) wait0 ;
(:
Barging is possible. A thread calling P might get in the monitor before a thread notified with V can get back in the monitor. Both P calls will then succeed when only one should, a safety violation. The f?x for this is to change the if in front of the wait 0 to a while. 4.2 Second Attempt ( 3
3 public synchronized void VO ( value++ ; if (value <= 0) notify0; 3
public class CountingSemaphore private int value = 0; public ( if CountingSemaphore(int (initial > 0) value
initial) = initial;
)
This fixes the barging problems but introduces an interrupt (> problem. Suppose the semaphore value is -1 due to one thread blocked in wait 0 inside P. Then suppose that thread is interrupted. The value is left at -1 even though no threads are blocked in P. The next
60
V will increment the value to 0 whereas it should now be 1. The fix for this is to count the wait set separately, rather than letting the semaphore value go negative. Another, more insidious problem is present: a race condition between interrupt ( ) and not if y ( ) . Suppose several threads are blocked inside wait 0 and then one of them is notified and then interrupted before it reacquires the monitor lock. The not if y 0 gets "lost" in that one of the other waiting threads should now proceed. So we need to catch the exception when a thread is interrupted out of wait 0 and regenerate the notifyo.
4.4 Fourth Attempt
private private public ( if public
int waitcount = 0; boolean notified = false; CountingSemaphore(int (initial > 0) value initial) = initial;
)
public class CountingSemaphore private int value = 0; private int waitcount = 0; public ( if public CountingSemaphore(int (initial > 0) value
(
initial) = initial;
synchronized void PO throws InterruptedException { if (value == 0 I I waitcount > 0) < waitCount++; try ( do ( wait(); ) while (!notified); 1 catch (InterruptedException e) C notify0 ; throw e; ) finally ( waitCount--; 1 notified = false; 3 value--;
)
3 public synchronized void value++ ; if (waitcount > 0) ( notified = true; notify0 ; V() (
synchronized void P() throws InterruptedException ( if (value == 0 I I waitcount > 0) ( waitCount++; try f wait0 ; 1 catch (InterruptedException e) ( notify0 ; // regenerate throw e; 1 finally ( waitCount--; 1 3 value-- ;
3
3 3 Suppose multiple threads are blocked inside wait 0 in P and some other thread calls V. Because several additional V calls might barge into the monitor before a notified thread reacquires the monitor lock, we must make the notification flag an integer counter to avoid "lost" notifies.
4.6 Sixth Attempt
3 public synchronized void V() < value++ ; if (waitcount > 0) notify0; 3 3 We have fixed the problem of a notified thread being interrupted, but we have introduced a new problem. Suppose a thread blocked inside wait 0 is interrupted before being notified. The not if y 0 it does in its catch block will move some other waiting thread, if there is one, out of the wait set into the lock (re)acquire set. When that thread gets back into the semaphore monitor, its P operation will complete successfully, an error. The fix is to add a notification flag so a thread can distinguish between the notify0 in V and the notify0 in the catch block.
4.5 Fifth Attempt
public class CountingSemaphore ( private int value = 0; private int waitcount = 0; private int notifycount = 0; public { if public CountingSemaphore(int (initial > 0) value initial) = initial;
1
public class CountingSemaphore private int value = 0;
(
synchronized void PO throws InterruptedException ( > 0) C if (value == 0 I I waitcount waitCount++ ; try ( do C wait () ; 1 while (notifycount == 0); ) catch (InterruptedException a) ( notify0 ; throw e;
61
1 fin...