JAVA-BASED REAL-TIME PROGRAMMING

3. Multi-Threaded Programming
by semaphores). When an object has been locked by synchronized (for a
method or a blocks), there can be conditions that need to be fulfilled before
the operations on the shared data can be fulfilled. Java provides the following
support for that situation.
3.3.2 Conditions – wait and notify
Consider a buffer with operations put and get. To accomplish mutual exclusion
during manipulation of the buffer, those methods are typically declared
synchronized. However, both in this case as well as in many other types of
monitors, certain conditions may need to be fulfilled before an operation can
be completed. For instance, there must be something in the buffer to fetch
before get can be performed, and the buffer may not be full in order to let put
be carried out. If such conditions can be evaluated before any shared data is
manipulated we could simply cancel the operation and make a new call when
the status has changed, but we also require:
• When waiting for a certain condition to be fulfilled, that thread should
be blocked to prevent waste of CPU time (polling or busy wait, possibly
leading to starvation of other threads, is not allowed).
• When the condition is fulfilled we need a way of waking up the blocked
thread(s).
• When a thread continues execution after being blocked on some condition,
it has to compete for the resource again since we have to ensure
that only one thread at a time is executing inside the monitor (i.e., inside
the critical region).
To accomplish these features, each Java object is equipped with a wait/notify
mechanism in terms of the methods wait, notify, and notifyAll according to
(see Figure 3-7):
wait() The thread executing within the monitor (inside a synchronized method
or block) gives up the exclusive access, stepping out to the ’back yard’
containing the condition queue. The runtime system puts the blocked
thread in the condition queue, where it typically is inserted in priority
order with the thread with the highest priority first. The saved context
of the blocked thread, referring to the stack of the thread and thereby
to the state of execution, of course contains the state of the half made
monitor operation.
notify() Threads waiting in the condition queue will remain there until notified
by some other thread, or until a timeout occurs as explained later.
Threads that inside the monitor change any data that affects conditions
that the threads in the condition queue might waiting for, should call
74 2012-08-29 16:05