JAVA-BASED REAL-TIME PROGRAMMING

3.3. Objects providing mutual exclusion – Monitors
converting it to an RTInterrupted in whatever monitor it occurs, we can then
catch the RTInterrupted and terminate the thread like:
class RobotDuty extends Thread {
public void run() {
try {
while (doWork(Master.nextInstruction ())) {};
} catch (RTInterrupted) { Master.workAborted ();} // Acknowledge.
} // No more work; end of duty!
}
Terminating the thread (and creating a new one for the next work) like in this
example is convenient for handling sessions that have a finite life time, such as
processing a batch recipe in a chemical industry, or carrying out an e-business
transaction; the state of the session is kept by the thread, and both the activity
and the state gets garbage-collected when the session is finished. In feedback
control, on the other hand, we usually create the threads that execute during
the entire lifetime/uptime of the system; the state of the controlled system
needs to be maintained also over mode changes and the like, and the control
can be sensitive to delays during creation of new threads.
3.3.3 More on monitor programming
The following applies to the use of standard Java packages, whereas enhanced
support for monitors will be introduced in Chapter 4.
Static monitors – locking class variables
Executing synchronized code results in the synchronized object being locked.
That is, mutual exclusion is provided for the object (not the class) and concurrent
access to different objects of the same class is, of course, still permitted.
However, there may be attributes that are shared between all objects of a
certain type, so called static attributes or class variables. Mutual exclusion
then requires special care. Even if the object provides mutual exclusion on its
attributes, for instance by having all attributes private and all non-static methods
synchronized, the class variables are still not locked. The reason is that
the class as such is another object which needs to be locked separately, either
by a static synchronized method or by a synchronized(static_attribute){}
block. In the same way, since a static method has no reference to ’this’ object,
a static method does not provide mutual exclusion for any non-static methods.
Hence, locking for classes (static attributes) and objects are different things,
implying that a inside a synchronized method locking either the class or the
object, you have to put a synchronized block for explicitly locking the other,
if both the class and object need to be locked at the same time.
83