JAVA-BASED REAL-TIME PROGRAMMING

2.4. Concurrency
a trend that the parallelity is fully taken care of by the hardware. Hardware
developers talk about the “sequence control barrier” which means
that the hardware parallelity may not violate the sequencing property
of the software execution as described in Section2.1. Thus, even if we
should use a PC running Windows on four CPUs, we do not have to
care about that when writing our software.
In conclusion, the sequential execution model described earlier is almost always
valid even when parallel computers are used. Comments about software
interfaces between different processors will be given in a few places in this
book, but generally we should think in terms of using a single CPU.
2.4 Concurrency
Our software applications interact with users and external equipment via input/output
interfaces, generally called the IO. The computer receives input
data concurrently from sensors and from user input devices like keyboard,
mouse, and microphone, as depicted in Figure 2.2. From the user we talk
about input events, and from the sensors we talk about samples. Both input
events and samples reach our program in form of some kind of data entity
or record. For a mouse click, for example, the event typically contains the
horizontal and vertical coordinates on the screen and the time when the click
occurred. Sampled physical values for feedback control are usually obtained
via dedicated IO interfaces with well defined timing and buffering; extra delays
in terms of unforeseen buffering could cause the feedback control to be
unstable. There is no clear distinction between the two loops in Figure 2.2
(for instance real-time games only have one type of loop and physics is directly
available to the user/driver in vehicles), but it is normally good to be
aware of it for engineering purposes. Assume we only know ordinary sequential
programming. Even if we use object oriented design and programming,
with classes and objects defined according to real-world objects, methods are
sequential and called sequentially so we still have the same situation as commented
in the beginning of this chapter. Physically, all input may occur in
parallel, and we can generally not make any assumptions about the resulting
order of the data that is input to our program. The problem with pure
sequential programming is that the programmer must define in what order
computing should be done, but it is not known in what order input data
will arrive, or the program has to waste CPU time on excessive polling and
evaluation of conditions that may influence the output.
For example, reconsider the LEGO-brick machine. Assume we have implemented
the control program as one loop in which all IO and control is
carried out sequentially. Then consider what the changes will be if, say, the
sampling frequency of the temperature control is substantially changed. Since
21