JAVA-BASED REAL-TIME PROGRAMMING

3.3. Objects providing mutual exclusion – Monitors
(for example in unknown subclasses) can interfere. Therefore, a delay within
a monitor should be implemented similar to:
synchronized monitorSleep(long timeout) throws InterruptedException {
long tf = System.currentTimeMillis ()+timeout;
while ((timeout=tf-System.currentTimeMillis ())>0) wait(timeout);
}
Also note that if timeout milliseconds elapsed from the call of wait until the
calling thread executes the instruction following wait, we cannot distinguish
between if:
1. The wait was called and timeout ms later we continued after a timeout.
2. The wait was called and before the timeout time some other thread called
notify, but due to scheduling more than timeout ms elapsed before the
statement after wait was executed.
3. Other threads were scheduled for execution right before wait was actually
called, then during the wait some other thread called notify, but
due to the initial delay more than timeout ms elapsed.
Thus, even if it is only in case 1 that the runtime system issued a timeout, we
can obtain waiting for that amount of time due to the (platform dependent)
scheduling. In code this means, dt can be greater than timeout even if wait
was completed due to a notification:
long t0 = System.currentTimeMillis ();
wait(timeout);
long dt = System.currentTimeMillis()-t0;
Is this a problem? Normally not; it does usually not matter if we were notified
or not, it is the inferred delay that matters for the calling thread. Hence, if
dt>timeout it is considered as a timeout. On the other hand, if the state of
the monitor stated that our thread was waiting, and some other thread calling
notifyAll determined that it issued the notification on time (before a timeout
occurred) and subsequently acted according to that, the possible cases 2 and 3
above may imply a need for some more monitor logic. That is, if it logically is
not a timeout, only checking if dt>timeout after the previous code fragment
is not sufficient; concurrency correctness may require some more monitor logic
to cope with all possible interleavings, as always.
Interrupted waiting
When a thread that is blocked on wait (with or without timeout), or on sleep
as described on page 51, the blocking is interrupted and an InterruptedException
is thrown to the calling thread. The appropriate handling of such
an interrupted wait is typically known/defined in the calling thread outside
the monitor methods. Hence, it must propagate to the caller, so the obvious
81