JAVA-BASED REAL-TIME PROGRAMMING

3.3. Objects providing mutual exclusion – Monitors
1. There is the risk that x or y gets corrupted when the program is not
run on a 64-bit machine (where a double is stored in a single machine
word), which is the normal case for embedded software. One remedy is
to use the atomic classes that are part of Java from J2SE 5.0, but that
is not easily applicable in other programming languages (and therefore
not further treated here).
2. Even if we would use single precision (float) for x and y, thereby avoiding
the problem of item 1 without using atomic classes (that decrease performance),
and even if we never get a context switch at the critical point
(e.g., due to the priorities and scheduler/OS used) between the calls of
fx and fy, the result of another thread calling dist could still be wrong or
outdated! The reason is that data can remain in registers of the CPU,
as resulting from an optimizing compiler since we have not provided
any information about the data being shared by multiple threads. The
remedy here is to declare the attribute volatile like:
private float volatile x, y;
Problems arise when data shared by multiple threads is not volatile or is
not protected with proper mutual exclusion (such as synchronized that
results in the runtime system being informed and the contant of the
cash is written to memory). Without volatile, a variable updated by
one thread may remain in a register while another thread reads from
the primary memory according to the address of the variable, and consequently
the old value is obtained instead of the one updated by the
other thread.
Even if there is really only one error in the PathCoord class above (the mix-in
of the monitor in the thread), we have now listed four different faults that
can be the result. Note that these problems all disappear if access object
attributes by methods that are synchronized, and also note that the first four
problems illustrated in the class PathCoord are the same if we use monitors
or semaphores for mutual exclusion, and the problems are the same in Java
as in C/C++. Thus, independently of which of these languages you use,
implement monitors and mutual exclusion as described 2 , and do not mix
active objects and monitors.
Synchronization details
As with any set of basic rules, there are some cases when the experienced
programmer for good reasons, or the beginner for bad reasons, may want to
2 When accomplishing mutual exclusion in Java via a proper monitor with synchronized
methods, or when a program written in C uses semaphore functions from some library of the
system, professional programmers are usually aware of the preemption aspect represented
by the described concurrency fault (first error) of the PathCoord class. As a (positive) side
effect the other possible runtime errors also disappear.
71