JAVA-BASED REAL-TIME PROGRAMMING

2. Fundamentals
Definition: The correctness of a concurrent program does not only require
each programmed sequence of computation to be correct, the correct result
must also be obtained for all possible interleavings.
In terms of the bank example this means that money should not be (virtually)
lost or created due to the timing of transactions and computer operations.
Even if that is an obvious requirement, it is actually a quite severe demand
when it comes to verification of the correctness and finding any faults; the
task we call test and debugging. Debugging an ordinary sequential program
can be done by running the program with all possible sets of input data, and
one set of input data gives the same result if the program is run again. For
a concurrent program, however, the interleaving depends on external events
triggering different sequences of scheduling and execution. With a concurrent
program, we can usually not expect to obtain the same execution order
twice; an input event occurring just a microsecond later may result in another
interleaving which may course an incorrect program to crash. That in turn
must not happen for a safety critical application. Hence, we may have severe
requirements on correctness but complete testing is almost never possible.
It is interesting to note that the definition of correctness does not say
anything about time or timing, but timing is both the main reason for introducing
concurrency and the key aspect for the behavior of an incorrect
program. Considering the difficulties writing and testing concurrent software,
our hope now is that we can find and follow certain rules for development of
such software.
2.5 Interrupts, pre-emption, and reentrance
Just like we did not allow the user program to poll the inputs for possible
events (which would be waste of computing power when no new event has
arrived), the same applies to the scheduler or scheduling. The invocation of
the scheduler and its implications for the software application deserve some
comments.
2.5.1 Obtaining the time base
As mentioned, we resort to using hardware interrupts to trigger our software
functions, even if the interrupt service routines as such are hidden inside the
operating system and device drivers. Of course, we may have input signals
which do not generate any interrupt, but then we read that value at certain
times, usually periodically when the data is used for feedback control. Therefore,
the scheduler should also be able to handle time requests, such as “sleep
one second” which then should suspend execution for that activity during that
period of time.
Hence, our computer must be equipped with some kind of timer interrupt
occurring periodically, thereby providing a time base for the software. Of
26 2012-08-29 16:05