JAVA-BASED REAL-TIME PROGRAMMING

3.3. Objects providing mutual exclusion – Monitors
• We now have two threads in the condition queue, one consumer
blocked on buffer empty and one producer blocked on buffer full,
and one of them will most likely be stuck there for a long time
(possibly forever if it was the producer and if that thread was to
serve the next application event). This holds even if we would have
implemented the Buffer using while instead instead of if according
to item 1, but the remedy of item 2 works.
Items 2 and 3 are similar in that they both motivate the use of notifyAll
instead of notify. The difference is that while we according to item 2 actually
may be able to optimize and use notify, fully tested to be logically correct on
one JVM/OS, item 3 points at the concurrency problem that implies the risk
of application failure sometimes on some platforms.
Another problem is that at any place within your program, where a reference
to your monitor is available, synchronized(monitor){monitor.notifyAll();}
can be called and interfere with your methods. The same of course applies
to notify and wait. The remedies above help also in this case. For optimized
libraries, however, private notification objects can be used, like the private
lock object described in the above section about Synchronization details.
A radical remedy would be to always notify all threads whenever anything
has changed. For instance, the Buffer class in Figure 3-8 could be implemented
like in the left version in Figure 3-9, where the suggestions from the above
items have been considered. Decreased performance comes from notifyAll
(which is a system call that is more expensive than checking ordinary data)
being called even if there for sure is no thread in the condition queue, and
there are no logic separating between the full and empty cases. A reasonable
trade-off (using notifyAll to avoid the described problems) is shown to the
right in Figure 3-9.
In short, as rules of thumb for programming:
1. Always use while in front of wait: while (!okToProceed) wait();
2. Instead of notify(): use notifyAll();
3. Tune performance when needed, using notify() or condition objects explained
below.
Keep Figure 3-7 in mind when you develop your monitor methods.
Timeout on waiting
There are situations when waiting for a condition to be fulfilled may not take
more than a certain amount of time. After that time we want to get a timeout.
For this purpose, there are two versions of wait accepting timeout arguments:
79