JAVA-BASED REAL-TIME PROGRAMMING
JAVA-BASED REAL-TIME PROGRAMMING
JAVA-BASED REAL-TIME PROGRAMMING
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
3. Multi-Threaded Programming<br />
}<br />
System.out.println("World!");<br />
}<br />
public void run() {<br />
System.out.print("and goodbye ");<br />
}<br />
A few test runs on a 200MHz Pentium-MMX running Windows-NT4 gave:<br />
> javac HelloWorld.java<br />
> java HelloWorld<br />
Hello and goodbye World!<br />
> java HelloWorld<br />
Hello World!<br />
and goodbye<br />
> java HelloWorld<br />
Hello World!<br />
and goodbye<br />
> java HelloWorld<br />
Hello and goodbye World!<br />
Hence, the output from the program varies from time to time. In most cases<br />
we need a well defined output, independent of the timing. For instance, "Hello"<br />
and "World!" could correspond to parts of a ticket printout and the printing of<br />
"and goodbye" could correspond to the result from a data-base access. Then<br />
waiting for the data-base result by calling sleep(1) clearly is the wrong way of<br />
waiting since it makes the correctness of the output dependent on the timing<br />
of computing platform. The problem is, however, that developing and testing<br />
the application on one type of machine does not imply correct output on<br />
another (customer) machine. In particular, if the machine is a robot or a<br />
vehicle (instead of a desktop computer), we certainly need additional rules for<br />
how to program.<br />
Note that even if we would know the properties of the execution environment<br />
(OS, CPU-type, clock frequency, speed and amount of memory,<br />
other applications, level of patches or service packs, etc.), and testing verifies<br />
the correctness of the system, the program as such is not correct<br />
from a concurrency point of view.<br />
3.1.5 Scheduling – Priorities<br />
The number of concurrently executing activities (threads or processes) is in<br />
practice always greater than the number CPUs available, which implies that<br />
all work cannot be worked on immediately. The support for concurrent execution<br />
(multi threading etc.) solves this problem, if we have no demands on<br />
timely response. In other words, for purely concurrent software, we can let<br />
the run-time system schedule our activities in any feasible way that lets all<br />
activities run. However, if the application requires certain response times or<br />
performance, in particular when the CPU load is high, we may need to tell<br />
48 2012-08-29 16:05