JAVA-BASED REAL-TIME PROGRAMMING

to foresee the value actually returned. Let us look into a few basic aspects:
• Time quantization: Waiting for the next ms does not mean waiting for
1 ms. In fact, running on a 100 MHz CPU it may take only 10 nanoseconds
(1 CPU cycle) until a new clock interrupt is served and the time
(in software) is incremented. The real time between the readings will
then be only the time to run lines 2 to 5, plus the service time for the
clock interrupt, say 0.1 us giving a relative error of 1000000%! Ignoring
the (quite small) computation time we see that even with the same
numerical time values, the difference in real-time between two time readings
(depending on when during the so called tick period each reading
was done) can be up to (but not quite) two clock ticks.
• Scheduling: It can on the other hand also be the case that the new clock
tick causes another thread to be scheduled and the next reading takes
place one second later. So even with a maximum of two ticks (2 ms)
quantization error, the maximum trend error will be 0.2% Note again,
the actual schedule (and thereby the returned value) is not expressed in
the program; it depends on the system.
• Efficiency: The longer execution is suspended between lines 3 and 4,
the better the estimation of a constant trend gets 1 . The waiting for
the second sampling time above was done by a so called busy wait. In
rare situations this way of waiting for a condition to be fulfilled can be
useful, but especially for longer delays it causes efficiency problems (and
also response problems if real time is considered). A busy wait actually
asks for 100% of the CPU time. A better approach would be to inform
the thread scheduling that we permit other threads to run for a certain
period of time. That is the purpose of the sleep method treated below.
• Time-stamp deficiency: Suspended execution (and incrementing time)
between lines 2 and 3, or between lines 4 and 5, also causes a bad trend
error to be computed. This holds regardless of how small the time
increments are, that is, even with the high resolution clock mentioned
above. Also, if we swap lines 2 and 3, the program should be the same
from a sequential computing point of view, but due to the System call
it is not; the t can deviate in different directions which creates trend
errors in different directions.
The fact that we care about when an input value was sampled can be looked
upon as if we would like to have a time-stamped value. That is, the value and
1 For a changing input value, however, we need a short delay to get a fresh estimation.
In real-time software we need to manage such trade-offs and preferably express the required
execution timing in the source code, or we have to impose requirements on the run-time
system. For now we only deal with time-dependent software which should not be confused
with real time.
3.1. Threads
45