JAVA-BASED REAL-TIME PROGRAMMING

3. Multi-Threaded Programming
• Since C1 is continuing after wait, according to the shown implementation
assuming that the buffer is not empty, C1 tries to get
the next object. There are no such object, and the buffer (and the
application) fails 4 .
2. It can be difficult to keep track of what condition other threads are blocked
on, or it can be hard to verify correctness or revise the code. In the referred
buffer example it may appear to be simple, but does the buffer
work correctly even for maxSize equal to one?
If we would add another method awaitEmpty that should block until the
buffer is empty (useful during application shutdown), or an additional
method awaitFull that should block until the buffer is full (useful for
special handling of overflows), when and how many times should notify
then be called?
It is so easy to overlook some cases, and actually taking care of all cases
by the appropriate logic (such as counters for threads blocked on this
or that condition) leads to unnecessary complex code that is hard to
understand and maintain.
Remedy: Use notifyAll instead of notify, and let other threads reevaluate
their conditions (assuming the remedy for item 1 is used). The
exception from this rule is when optimizing for well known and performance
critical parts of the application.
3. How do we ensure concurrency correctness and predictability on any
(Java-compatible) platform? As an example, assume we have two consumer
threads (C1 and C2) and five producer threads (P1 to P5), and
assume these use our buffer according to the following:
• The buffer (Buffer in Figure 3-8) is given a capacity of four (maxSize==4).
• Both C1 and C2 call fetch, and hence they get blocked since the
buffer is empty.
• P1 puts an object in the buffer by calling post, which calls notify.
One of C1 and C2, say C1, is moved to the monitor queue while
the other consumer remains in the condition queue.
• Before C1 gets scheduled for execution, the other producers (P2 to
P5) try to post an object. Since the buffer was not empty, C2 was
not notified. This is either a bug or C1 has to notify C2 somehow.
However, the last producer, say P5, then also gets scheduled before
C2 and post blocks since the buffer now is full.
4 Programming in Java, application failure typically means an ArrayOutOfBoundException
or a NullPointerException that can be caught and handled, or at least we know what
and where it went wrong. Using an unsafe language such as C++, the system can crash (at
a later stage) without messages.
78 2012-08-29 16:05