Synchronization
The communication of a message between two processes implies some level of synchronization
between the two: The receiver cannot receive a message until it has
been sent by another process. In addition, we need to specify what happens to a
process after it issues a send or receive primitive.
Consider the send primitive first. When a send primitive is executed in a
process, there are two possibilities: Either the sending process is blocked until the
message is received, or it is not. Similarly, when a process issues a receive primitive,
there are two possibilities:
1. If a message has previously been sent, the message is received and execution
continues.
2. If there is no waiting message, then either (a) the process is blocked until
a message arrives, or (b) the process continues to execute, abandoning the
attempt to receive.
Thus, both the sender and receiver can be blocking or nonblocking. Three
combinations are common, although any particular system will usually have only
one or two combinations implemented:
• Blocking send, blocking receive: Both the sender and receiver are blocked until
the message is delivered; this is sometimes referred to as a rendezvous . This
combination allows for tight synchronization between processes.
• Nonblocking send, blocking receive: Although the sender may continue on,
the receiver is blocked until the requested message arrives. This is probably
the most useful combination. It allows a process to send one or more messages
to a variety of destinations as quickly as possible. A process that must receive
a message before it can do useful work needs to be blocked until such a message
arrives. An example is a server process that exists to provide a service or
resource to other processes.
• Nonblocking send, nonblocking receive: Neither party is required to wait.
The nonblocking send is more natural for many concurrent programming
tasks. For example, if it is used to request an output operation, such as printing, it
allows the requesting process to issue the request in the form of a message and then
carry on. One potential danger of the nonblocking send is that an error could lead
to a situation in which a process repeatedly generates messages. Because there is no
blocking to discipline the process, these messages could consume system resources,
including processor time and buffer space, to the detriment of other processes and
the OS. Also, the nonblocking send places the burden on the programmer to determine
that a message has been received
