JAVA-BASED REAL-TIME PROGRAMMING

3. Multi-Threaded Programming
via synchronized methods. However, the concurrency correctness would then
heavily depend on programming discipline; neither the compiler nor the runtime
system can complain about the run method accessing the attributes (run
is nothing special from a language point of view). The public, protected, and
private, keywords have to do with visibility between ordinary objects; they
have nothing to do with concurrency. In case of mixing threads and monitors
we get no help from the compiler as when we use synchronized methods to
access protected attributes. The lack of support for the Task abstraction
could be considered as a deficiency of Java, but as will be argued later, the
task is not a suitable abstraction for the design of object oriented concurrent
(or real-time) systems anyway.
Use and misuse of keyword volatile
To further descriebe the special need for concurrent software to be wellstructured
the following code snippet contains a synchronized method in a
thread object. By breaking rule A above we may say that we have one error,
and there is a risk that mutual exclusion will not work, but what other
problems can result?
/*
* Find four faults , concerning concurrency , in this class.
*/
import I.robot.dest; // Import static robot destination class Dest.
public class PathCoord extends Thread {
private double x,y;
public synchronized int dist() {return Math.sqrt(x*x+y*y);}
public void int run() {
double path = 0.0; // Path coordinate , locally on thread stack.
while(!isInterrupted ()) {
path = Dest.step(path); // Local data and reentrant method.
x = Dest.fx(path); // Calling one thread -safe method ,
y = Dest.fy(path); // and calling another one.
Dest.nextStep(x,y); // Use x,y and wait for next sample.
}
}
}
Even if this program is run on 64-bit machine (with the doubles being atomically
assigned, more on that below), it can happen that a valid value x is
not consistent with a valid value y (together defining an invalid coordinate
outside the path for the destination of the robot motion). This is a concurrency
error due to preemption (between or in the calls of fx and fy, since run
as usually is not synchronized), independently of the types of x and y, and
despite that fx and fy each are thread safe. Hence, this is a concurrency fault
and the outcome of running the software is dependent on the execution timing
and scheduling. In combination with breaking the rule not to mix threads
and monitors, we may say this constitutes two errors in this class. However,
there are also two other concurrency problems that are common in embedded
software since most programmers also in industry are not aware of this:
70 2012-08-29 16:05