JAVA-BASED REAL-TIME PROGRAMMING

2. Fundamentals
Both a process and an interrupt contain threading and some kind of execution
state, but a process is more powerful than a thread whereas an interrupt
is less powerful. In more detail:
• A process may contain one or several threads which we then say are
internal to the process. The internal threads share a common address
space in which they can share data and communicate without having to
copy or transfer data via pipes or files. An object reference (or pointer
in C/C++) can be used by several threads, but sharing objects between
processes requires special techniques. The same applies to calls
of member functions. All threads of one process have the same access
rights concerning system calls, file access, etc. Different processes, on
the other hand, may have different access rights.
The concept of a process makes it possible to isolate execution and data
references of one program. By controlling the MMU (Memory Management
Unit) accordingly, an illegal data access (due to dereference of a
dangling pointer in a C program for instance) can be trapped and handled
by the operating system. To the UNIX user, there will be something
like a “segmentation fault” message. In Windows 95/98, which
lacks this support, one application programming error may crash other
applications or even hang the operating system.
• An interrupt starts a new execution thread, but it is subject to special
restrictions. First, it must complete without blocking because it may not
change execution state (switch context). Second, the interrupt may only
start in a static function/method because this type of hardware call does
not provide function arguments such as the implicit this pointer. Third,
an interrupt may run within the context of another thread because the
final restore of used registers and the requirement of “execution until
completion” ensures that the context of the interrupted thread will be
restored. The priorities of interrupts are managed by the hardware.
Thus, whereas threads will be the most common way to accomplish concurrently
executing software entities, an ISR is sometimes more appropriate or
even necessary (device drivers), or there may be reasons for using (OS) processes
instead of threads. Device drivers cannot be (purely) implemented in
Java, and such machine-level programming is outside the scope of this book;
it is well known how to do that and there are several hardware/OS-specific
manuals/books on the topic. The issue of multithreading versus multiprocessing
is more relevant, in particular for large complex systems, deserving a more
detailed treatment.
36 2012-08-29 16:05