06.08.2013 Views

JAVA-BASED REAL-TIME PROGRAMMING

JAVA-BASED REAL-TIME PROGRAMMING

JAVA-BASED REAL-TIME PROGRAMMING

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

synch.<br />

T1 entry<br />

give<br />

take<br />

3.2. Resources and mutual exclusion – Semaphores<br />

exit T2<br />

take<br />

give<br />

Figure 3.4: Rendezvous accomplished by two (signaling) semaphores. Synchronization<br />

takes place in the interval marked sync.<br />

in Java. Still, rendezvous is useful when data is to be handed over from one<br />

thread to another. That is, not only transferring data between the thread<br />

objects (without buffering), but also making sure that the receiving thread of<br />

execution has arrived in a state where the data has been accepted.<br />

Figure 3.4 illustrates the rendezvous concept and how to implement it<br />

using semaphores. Note that T1 is blocked during synchronization when only<br />

T2 accesses the shared data. The ’sync.’ interval for T2 therefore corresponds<br />

to a critical section, and T2 may not use the shared data before entry.take and<br />

after exit.give. For T1 on the other hand, shared data may be manipulated<br />

until entry.give is called (which is to be directly followed by exit.take) and after<br />

(blocking ends after) exit.take. Thus, T1 is so to say in the critical section<br />

all the time, but blocked when communication takes place. Since interaction<br />

with T2 is required before T1 can proceed, it is easy to imagine situations<br />

when the use of rendezvous as the only mean for synchronization gets clumsy.<br />

Metaphors for semaphores<br />

With the semaphore classes available, one has to keep in mind when to use<br />

what class (semaphore use cases). It is then useful to have some mental picture<br />

of how the different semaphore classes are to be used. Since semaphores (in<br />

real life) historically come from railroad traffic, a train control example will be<br />

used. Note, however, that this has very little to do with railroad semaphores<br />

as such; it is only our semaphore classes used in a railroad context.<br />

In Figure 3.5 there is a semaphore mutex used to having only one train at<br />

a time on the track for unloading (shared resource), and there is a semaphore<br />

signal used for signaling the availability of items in the buffer between the track<br />

for unloading and loading. The (passive) buffer permit the (active) trains to<br />

access the items independently (asynchronously) of each other, as long as the<br />

buffer is not empty. The zone to the lower right, on the other hand, provides<br />

synch.<br />

61

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!