CHAPTER5 Process Synchronization Now that we have provided a grounding in synchronization theory, we can describe how Java synchronizes the activity of threads, allowing the programmer to develop generalized solutions to enforce mutual exclusion between threads. When an application ensures that data remain consistent even when accessed concurrently by multiple threads, the application is said to be thread-safe. 5.1 Bounded Buffer In Chapter 3, we described a shared-memory solution to the bounded-buffer problem. This solution suffers from two disadvantages. First, both the producer and the consumer use busy-waiting loops if the buffer is either full or empty. Second, the variable count, which is shared by the producer and the consumer, may develop a race condition, as described in Section Section 5.1. This section addresses these and other problems while developing a solution using Java synchronization mechanisms. 5.1.1 Busy Waiting and Livelock Busy waiting was introduced in Section 5.6.2, where we examined an imple- mentation of the acquire() and release() semaphore operations. In that section, we described how a process could block itself as an alternative to busy waiting. One way to accomplish such blocking in Java is to have a thread call the Thread.yield() method. Recall from Section Section 6.1 that, when a thread invokes the yield() method, the thread stays in the runnable state but allows the JVM to select another runnable thread to run. The yield() method makes more effective use of the CPU than busy waiting does. In this instance, however, using either busy waiting or yielding may lead to another problem, known as livelock. Livelock is similar to deadlock; both prevent two or more threads from proceeding, but the threads are unable to proceed for different reasons. Deadlock occurs when every thread in a set is blocked waiting for an event that can be caused only by another blocked thread in the set. Livelock occurs when a thread continuously attempts an action that fails. 143 144 Chapter 5 Process Synchronization // Producers call this method public synchronized void insert(E item) { while (count == BUFFER SIZE) Thread.yield(); buffer[in] = item; in = (in + 1) % BUFFER SIZE; ++count; } // Consumers call this method public synchronized E remove() { E item; while (count == 0) Thread.yield(); item = buffer[out]; out = (out + 1) % BUFFER SIZE; --count; return item; } Figure 5.1 Synchronized insert() and remove() methods. Here is one scenario that could cause livelock. Recall that the JVM schedules threads using a priority-based algorithm, favoring high-priority threads over threads with lower priority. If the producer has a priority higher than that of the consumer and the buffer is full, the producer will enter the while loop and either busy-wait or yield() to another runnable thread while waiting for count to be decremented to less than BUFFER SIZE.Aslongastheconsumer has a priority lower than that of the producer, it may never be scheduled by the JVM to run and therefore may never be able to consume an item and free up buffer space for the producer. In this situation, the producer is livelocked waiting for the consumer to free buffer space. We will see shortly that there is a better alternative than busy waiting or yielding while waiting for a desired event to occur. 5.1.2 Race Condition In Section Section 5.1, we saw an example of the consequences of a race condition on the shared variable count. Figure 5.1 illustrates how Java’s handling of concurrent access to shared data prevents race conditions. In describing this situation, we introduce a new keyword: synchronized. Every object in Java has associated with it a single lock. An object’s lock may be owned by a single thread. Ordinarily, when an object is being referenced (that is, when its methods are being invoked), the lock is ignored. When a method is declared to be synchronized, however, calling the method requires 5.1 Bounded Buffer 145 acquire lock object lock owner entry set Figure 5.2 Entry set. owning the lock for the object. If the lockisalreadyownedbyanotherthread, the thread calling the synchronized method blocks and is placed in the entry set for the object’s lock. The entry set represents the set of threads waiting for the lock to become available. If the lock is available when a synchronized method is called, the calling thread becomes the owner of the object’s lock and can enter the method. The lock is released when the thread exits the method. If the entry set for the lock is not empty when the lock is released, the JVM arbitrarily selects a thread from this set to be the owner of the lock. (When we say “arbitrarily,” we mean that the specification does not require that threads in this set be organized in any particular order. However, in practice, most virtual machines order threads in the wait set according to a FIFO policy.) Figure 5.2 illustrates how the entry set operates. If the producer calls the insert() method, as shown in Figure 5.1, and the lock for the object is available, the producer becomes the owner of the lock; it can then enter the method, where it can alter the value of count and other shared data. If the consumer attempts to call the synchronized remove() method while the producer owns the lock, the consumer will block because the lock is unavailable. When the producer exits the insert() method, it releases the lock. The consumer can now acquire the lock and enter the remove() method. 5.1.3 Deadlock At first glance, this approach appears at least to solve the problem of having a race condition on the variable count. Because both the insert() method and the remove() method are declared synchronized,wehaveensuredthatonly one thread can be active in either of these methods at a time. However, lock ownership has led to another problem. Assume that the buffer is full and the consumer is sleeping. If the producer calls the insert() method, it will be allowed to continue, because the lock is available. When the producer invokes the insert() method, it sees that the buffer is full and performs the yield() method. All the while, the producer still owns the lock for the object. When the consumer awakens and tries to call the remove() method (which would ultimately free up buffer space for the producer), it will block because it does not own the lock for the object. Thus, both the producer and the consumer are unable to proceed because (1) the producer is blocked waiting for the consumer to free space in the buffer and (2) the consumer is blocked waiting for the producer to release the lock. 146 Chapter 5 Process Synchronization // Producers call this method public synchronized void insert(E item) { while (count == BUFFER SIZE) { try { wait(); } catch (InterruptedException e) {} } buffer[in] = item; in = (in + 1) % BUFFER SIZE; ++count; notify(); } // Consumers call this method public synchronized E remove() { E item; while (count == 0) { try { wait(); } catch (InterruptedException e) {} } item = buffer[out]; out = (out + 1) % BUFFER SIZE; --count; notify(); return item; } Figure 5.3 insert() and remove() methods using wait() and notify(). By declaring each method as synchronized, we have prevented the race condition on the shared variables. However, the presence of the yield() loop has led to a possible deadlock. 5.1.4 Wait and Notify Figure 5.3 addresses the yield() loop by introducing two new Java methods: wait() and notify(). In addition to having a lock, every object also has associated with it a wait set consisting of a set of threads. This wait set is initially empty. When a thread enters a synchronized method, it owns the lock for the object. However, this thread may determine that it is unable to continue because a certain condition has not been met. That will happen, for 5.1 Bounded Buffer 147 acquire lock wait object lock owner entry set wait set Figure 5.4 Entry and wait sets. example, if the producer calls the insert() method and the buffer is full. The thread then will release the lock and wait until the condition that will allow it to continue is met, thus avoiding the previous deadlock situation. When a thread calls the wait() method, the following happens: 1. The thread releases the lock for the object. 2. The state of the thread is set to blocked. 3. Thethreadisplacedinthewaitsetfortheobject. Consider the example in Figure 5.3. If the producer calls the insert() method and sees that the buffer is full, it calls the wait() method. This call releases the lock, blocks the producer, and puts the producer in the wait set for the object. Because the producer has released the lock, the consumer ultimately enters the remove() method, where it frees space in the buffer for the producer. Figure 5.4 illustrates the entry and wait sets for a lock. (Note that wait() can result in an InterruptedException being thrown. Wewill cover this in Section Section 5.6.) How does the consumer thread signal that the producer may now proceed? Ordinarily, when a thread exits a synchronized method, the departing thread releases only the lock associated with the object, possibly removing a thread from the entry set and giving it ownership of the lock. However, at the end of the synchronized insert() and remove() methods, we have a call to the method notify().Thecalltonotify(): 1. Picks an arbitrary thread T from the list of threads in the wait set 2. Moves T from the wait set to the entry set 3. Sets the state of T from blocked to runnable T is now eligible to compete for the lock with the other threads.