JAVA-BASED REAL-TIME PROGRAMMING

3.4 Message-based communication – Mailboxes
3.4. Message-based communication – Mailboxes
Instead of the low-level characteristics of semaphores, the desire to support
concurrency in an object oriented way led to monitors; passive objects used
to implement collaboration between active objects. In many cases, however,
we can benefit from having such passive objects with additional functionality
for:
Buffering: Often threads work in producer-consumer like situations when
transmitted objects need to be buffered in some type of queue. That lets
the threads work more asynchronously with respect to each other. That
is, even if there are some temporary blocking when posting/fetching
objects into/from the queue (to accomplish mutual exclusion during the
assumably short queuing operations), a buffer overall lets the threads
operate more independently of each other.
Activity interaction: Traditionally, before the email era, messages were
sent via mailboxes (passive objects providing buffering) and distributed
to the mailbox of the addressee. If the sender and receiver are close to
each other (like threads in the same JVM), and the sender knows (has
a reference to) where the receiver is, the overhead of distribution (cost
of the stamp and mail delay) can be avoided by putting the message
directly in the receivers mailbox. Anyhow, even if the messages (transmitted
objects) are buffered in a passive object (the mailbox), the aim
is to send it to some other active object (person), which deserves special
support.
Distribution: If the sender and the receiver of a message are not close to or
not aware of each others location, it is desirable to have some mail distribution
system. Even if the topic of distributed systems is outside the
scope of this chapter, communicating via messages makes us prepared
for the situation when each message has to be sent via ordinary mail; the
message can look the same, only the mailing differs. If we would call the
receiving active object directly, the addressee would need to be available
at that particular time. Therefore, communicating via messages can be
a good generic solution.
Encapsulation: Data protection (using private or protected in Java) ensures
encapsulation of sequential programs, which means that objects will be
ensured to function independently of each other. For real-time programs
that is not enough; when methods of another object is called from a
time-aware thread (looking at the clock frequently), the caller “gives up
it’s own will” and commits itself to performing the instructions given in
the (hidden) implementation of the called method, which can result in
blocking for a long time. Hence, threads give up their timely behavior
unless communication is performed differently.
85