JAVA-BASED REAL-TIME PROGRAMMING

3.3. Objects providing mutual exclusion – Monitors
withdraw method) but concurrent calls of withdraw can give the wrong
result. This is because the withdraw method no longer is reentrant. For
instance, one caller (with low priority) locks the resource and carries out
the transaction, while a second thread (with high priority) preempts the
first thread between lines 16 and 17. When resuming, the first thread
will return the result of the second call and the result of the first transaction
is lost, that is, if amount>balance.
Making a method or function reentrant by only using local variables (allocated
on the stack of each thread) is standard; we need to understand that no
matter if we use a language supporting synchronized or not. However, with
the availability of synchronized as in Java, we do not need to introduce the
ans variable at all. Furthermore, returning from a method never results in the
resource being left in its locked state; on return the Java compiler produces
the executable code that unlocks the object.
Basic use of keyword synchronized
There are cases when synchronized blocks are appropriate, but in general we
better follow a few simple rules:
1. For each class, decide if an instance should be an ordinary object (not
caring about concurrency), a thread object, or a monitor. Do not mix
threads and monitors.
2. Monitors should have all public methods synchronized (except the constructors)
and no public attributes. Subclasses of monitors should also
have to declare all methods synchronized since synchronized is not inherited.
3. If you need to make an ordinary class thread safe, you could create a
monitor by defining a subclass, but then you have to override all methods
in order to declare them as synchronized. Methods that are final is a
problem. Instead of subclassing, it is usually better to write a wrapper
class being a monitor containing the ordinary object.
4. Do not use synchronized blocks, which are contradictory to proper objectoriented
design of concurrent software and to the monitor concept as
such.
The reason for rule A is that the actions of a thread is defined via a method
(run) which from a purely object-oriented point of view is a method like any
other, with access to all attributes of the object. Mutual exclusion between the
internal thread (executing the run method) and the external threads (calling
the monitor methods) would require the run method to be synchronized as
well. Another alternative could be to only access the attributes of the object
69