JAVA-BASED REAL-TIME PROGRAMMING

3.2. Resources and mutual exclusion – Semaphores
MultistepSem Counting semaphore permitting increments and decrements that
are greater than one. Useful when two (or more) successive calls of take
needs to be done without risk for preemption in between.
MutexSem A Semaphore with special support for mutual exclusion. First, the
implementation may check that the thread calling give owns the lock
(that is, has taken the MutexSem). Secondly, this type of semaphore is
required to provide so called priority inheritance (see Chapter 4) as a
mean to obtain bounded response times for high priority threads when
a low-priority thread is preempted and then starved when in a critical
section.
In principle, not considering real-time requirements and assuming correct programming,
the MultistepSem could be used in all cases (or the CountingSem
in almost all cases), but providing and using suitable abstractions is valuable
in software development. Proposed usage:
• Declare semaphore attributes and arguments to be of type Semaphore,
except when the code is tailored to a specific type of semaphore.
• In normal cases, instantiate a MutexSem for mutual exclusion and a
CountingSem for signaling.
• In special cases, use the BinarySem for signaling when ’catching up’ is
not desired or for simplified resource reservation, and use the MultistepSem
for signaling multiple steps in an atomic manner or for atomic
reservation of multiple resources.
All Semaphore classes are declared final to permit optimal code and mapping
to native semaphores when cross-compiling to small embedded systems.
Errors and exceptions
When a blocking semaphore operation is interrupted, it results in SemInterrupted
being thrown. When a thread calls mutex.give (where mutex is an
instance of MutexSem) without first having acquired it by calling take, a
SemViolation is thrown. The caller is not expected to catch these, except for
properly shut-down of the application, since continued execution most likely
will violate resource allocation rules and result in concurrency faults. Therefore,
SemInterrupted and SemViolation are subclasses of java.lang.Error.
That also gives the benefit that calls do not have to be surrounded by trycatch.
When there are reasons to catch them, for instance right before thread
termination, that is of course possible.
65