Operating System

• Direct Communication
  –each process wanting to communicate must explicitly name the recipient or sender of the communication

–send and receive primitives defined:

send ( P, message ) : send a message to process P

receive ( Q, message ) : receive a message from process Q

–a link established automatically between every pair of processes that want to communicate»processes only need to know each other’s identity

–link is associated with exactly two processes

–link is usually bidirectional but can be unidirectional

•Asymmetric addressing:

–only the sender names the recipient

–recipient not required to name the sender

- need not know the sendersend ( P, message ) :

send message to process P
receive ( id, message ) : receive from any process, id set to sender

•Disadvantage of direct communications :

–limited modularity

- changing the name of a process means changing every sender and receiver process to match

–need to know process names

• Indirect Communication
  –messages sent to and received from mailboxes (or ports)

»mailboxes can be viewed as objects into which messages placed by processes and from which messages can be removed by other processes

–each mailbox has a unique ID

–two processes can communicate only if they have a shared

mailboxsend ( A, message ) : send a message to mailbox

A receive ( A, message ) : receive a message from mailbox A–a communications link is only established between a pair of processes if they have a shared mailbox

–a pair of processes can communicate via several different mailboxes if desired

–a link can be either unidirectional or bidirectional

–a link may be associated with more than two processes

»allows one-to-many, many-to-one, many-to-many communications

–one-to-many : any of several processes may receive from the mailbox

»e.g. a broadcast of some sort

»which of the receivers gets the message?

- ­arbitrary choice of the scheduling system if many waiting?

- ­only allow one process at a time to wait on a receive

• many-to-one : many processes sending to one receiving process

»e.g. a server providing service to a collection of processes

»file server, network server, mail server etc.

»receiver can identify the sender from the message header contents
•many-to-many :

–e.g. multiple senders requesting service and a pool of receiving servers offering service

- a server farm

•Mailbox Ownership

–process mailbox ownership :

»only the process may receive messages from the mailbox

»other processes may send to the mailbox

»mailbox can be created with the process and destroyed when the process dies­process sending to a dead process’s mailbox will need to be signalled

»or through separate create_mailbox and destroy_mailbox calls­possibly declare variables of type ‘mailbox’–system mailbox ownership :

»mailboxes have their own independent existence, not attached to any process

»dynamic connection to a mailbox by processes­for send and/or receive

•Synchronised versus Asynchronous Communications

•Synchronised:

–send operations blocking

»sender is suspended until receiving process does a corresponding read

–properties :

»processes tightly synchronised - the rendezvous of Ada

»effective confirmation of receipt for sender

»at most one message can be outstanding for any process pair­no buffer space problems»easy to implement, with low overhead–disadvantages :

»sending process might want to continue after its send operation without waiting for confirmation of receipt

»receiving process might want to do something else if no message is waiting to be received
•Asynchronous :

•send operations non-blocking

–sender continues when no corresponding receive outstanding

–properties :

»messages need to be buffered until they are received­amount of buffer space to allocate can be problematic­a process running amok could clog the system with messages if not careful

»often very convenient rather than be forced to wait­particularly for senders»can increase concurrency

»some awkward kernel decisions avoided

­e.g. whether to swap a waiting process out to disc or not

–receivers can poll for messages

»i.e. do a test-receive every so often to see if any messages waiting

»interrupt and signal programming more difficult

»preferable alternative perhaps to have a blocking receive in a separate thread

•Other combinations :

–non-blocking send + blocking receive

»probably the most useful combination

»sending process can send off several successive messages to one or more processes if need be without being held up

»receivers wait until something to do

i.e. take some action on message receipt­

e.g. a server process­ might wait on a read until a service request arrived,­ then transfer the execution of the request to a separate thread­ then go back and wait on the read for the next request

–blocking send + non-blocking receive

»conceivable but probably not a useful combination

–in practice, sending and receiving processes will each choose

• buffering
  
  - the number of messages that can reside in a link temporarily

Zero capacity - queue length 0

»sender must wait until receiver ready to take the message

Bounded capacity - finite length queue

»messages can be queued as long as queue not full

»otherwise sender will have to wait

Unbounded capacity

»any number of messages can be queued - in virtual space?

»sender never delayed

• Producer-Consumer Example

•Producer / Consumer problem using messages :

–Binary semaphores : one message token

–General (counting) semaphores : more than one message token

–message blocks used to buffer data items–scheme uses two mailboxes

»mayproduce and mayconsume

–producer :

»get a message block from mayproduce

»put data item in block»send message to mayconsume

–consumer :

»get a message from mayconsume

»consume data in block

»return empty message block to mayproduce mailbox