06.08.2013 Views

JAVA-BASED REAL-TIME PROGRAMMING

JAVA-BASED REAL-TIME PROGRAMMING

JAVA-BASED REAL-TIME PROGRAMMING

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!