Distributed Systems - Sync and Blocking Primitives

Definition of a Distributed System

A distributed system is one in which independent, self-sufficient, often autonomous and heterogeneous, spatially separated components must use a common interconnect to exchange information in order to coordinate there actions and allow the whole to appear to its users as one single coherent system.

IPC

IPC stands for InterProcess Communication. The most basic form of IPC that is known is when each process can act as either the sender or the receiver. A process may also act as both, but this only occurs during different points in the execution.

The Operating System (OS) within a computer provides several facilities for IPC’s. The most important facility that any OS can provide is an Application Programming Interface (API). API’s also rely on many other services, a couple of these are:

• To keep a network buffer. This is when the data waits to be either sent across the network on its way out or to be picked (received) once it has arrived at its destination process.


• To provide synchronization mechanisms so that a running process can be told that data has been sent and/or received.

API for IPC

There are lots of API’s for IPC’s, however, here we will discuss the basic API that exists. This basic API consisting of the following operations:

• SEND (receiver process) (data to be sent)


• RECEIVE – the argument for this operation is the location of where the data is to be placed, and possibly the sender process.

However, there can also be some cases of when an IPC is connection-oriented. In this case, more operations come into play:

• ACCEPT --  a receiver process calls this to specify its readiness to engage in communication


• CONNECT --  the sender process calls this to initiate the engagement


• DISCONNECT -- either process must use this operation to clearly disengage from communication.

Interaction Events

If a process wishes to communicate with other processes, then they must call these operations in a predetermined order. Each of these calls causes an interaction event to occur, for example:

• A call to SEND causes the event whereby the specified data is transmitted to the specified process.


• A call to RECEIVE causes the event whereby, upon the receipt of data from the sender, and then this data is placed in the specified location.

It is always crucial to remember that calls are being made separately, independently and remotely so that communicating process is able to know what is going on in any other communication process.

Synchronization / Blocking

The synchronization and blocking properties of SEND and RECEIVE always specify when control is returned to the invoking process. For SEND, the invoking process is the receiver process. For RECEIVE this is the sender process.

There are 4 forms of SEND:

Assume that SEND takes as a parameter the buffer in the sender process where the message is to be sent.  ::SEND (receiver process)(buffer)::

1. An asynchronous blocking SEND does not RETURN until the required message has been copied out of the buffer in the sender process.
   Note: this form does not wait for acknowledgement from the receiver process.


2. A synchronous blocking SEND does not RETURN until acknowledgement arrives back to the sender process that the required message has been placed into the buffer of the receiver process.


3. An asynchronous non-blocking SEND can RETURN before the required message has been copied out of the buffer from the sender process.
   This form, like the other asynchronous, also does not involve any acknowledgement from the receiver process.


4. A synchronous non-blocking SEND can also RETURN before acknowledgement arrives at the sender process that the required message has been place into the buffer of the receiver process.

Here, there are a few things to note.

• Forms 3 and 4 have a WaitFor[A]SynchronousSend primitive. This is called fro the sender process, and causes a signal to be passed to the sender process that the message has been copied into the buffer of the receiver process.


• Forms 1 and 3 require NO acknowledgement from the receiver process.

There are 2 forms of RECEIVE:

Like the sender process, assume that RECEIVE takes as a parameter the buffer in the receiver process of where the message is to be placed.  ::RECEIVE (buffer)::

It is probably common logic here to point out that RECEIVE is nearly always synchronous. This is because in both the blocking and non-blocking case, a RECEIVE cannot complete until a message has arrived in the receiver process. So an asynchronous RECEIVE would be just meaningless.

1. A blocking RECEIVE does not RETURN until the message has arrived and been copied into the buffer of the receiver process.


2. A non-blocking RECEIVE can RETURN before the message has arrived and been copied into the buffer of the receiver process.
   In this case, a WaitForReceive primitive is provided that will cause a signal to be passed to the receiver process that the message has been copied into its corresponding buffer.

NOTE: you can only combine synchronous SENDs with RECEIVE.