13ST - Inter Process Communication Pt III

8/6/2019 13ST - Inter Process Communication Pt III

1/18

EEE 435

Principles of Operating Systems

Interprocess Communication Pt III

(Modern Operating Systems 2.3)


2/18

Fall 2009 Course Notes

Quick Review


3/18


Outline

Three more concepts in InterprocessCommunication:

Monitors

Message Passing Barriers


4/18


Monitors

Have semaphores solved all of our problemswith Interprocess communication?

Recall Producer-Consumer example:


5/18


6/18


Monitors

AMonitoris used to aid in the creation ofcorrect programs

It is a collection of __________, _________, and

______________________ grouped together(think: module, package, class, etc)

Processes may call procedures in a monitor, but

the monitor is compiled in such a way that only

one process may ever be active in the monitor ata time

Advantage: les potentail forhumin error!

Disadvantage: Must be supported by the compiler


7/18


Monitors

This solution provides for mutual exclusion,but not for sleeping/waking on certain

conditions

To solve: include a condition variable insidethe monitor. This wont create a race

condition since only one process may be

active in the monitor at a time


8/18


9/18


Monitors

Signals are not accumulated in this system wait() must come before signal()

Not difficult considering only one process may be

in the monitor at a time

Exiting from the monitor after a signal() is

crucial to the operation

Otherwise, two process may be active in the

monitor simultaneously Other options include:

Suspending the process calling signal()

Allowing the process to finish and exit the monitor


10/18


Message Passing

Solutions to race conditions to this point haveassumed that information is accessible

through shared memory

How can this be done on a distributedsystem?

Message Passing is required


11/18


Message Passing

Uses two communication primitives, send()and receive()

System calls (like semaphores), not language

constructs (like monitors) receive() can either block until a message

arrives or return an error code (implementation

choice...do we use timeouts?)

Considerations: Message loss, Authentication, Performance,

Addressing


12/18


Message Passing

Considerations: Message loss:

_______________________________

______________________________________________________________

Authentication

How can the client tell it is communicating with the realfile server?


13/18


Message Passing

Considerations: Performance

Sending is much slower than a semaphore (even on asingle machine!) How much data may be passed?

Addressing: Messages can be addressed directly to the process or

to a mailbox structure, which would buffer messages

With no mailboxes, since the message may not be

buffered, th

e sending process must block until thereceiving process is ready. This allows a

synchronization of the two processes and is known asa _______________


14/18


Message Passing

Revisit Producer-Consumer Assume mailbox system exists

Assume messages are all the same size

Assume the mailbox buffers messages sent andnot received

N messages for this example

This implementation has the process block on a

receive() until a message arrives


15/18


16/18


Barriers

Barriers are a synchronization mechanism toalign multiple processes to the same phase of

work before proceeding to the next phase

Processes done the phase of their work call alibrary procedure [say barrier()] to block

until all processes have finished their work

Once all processes have completed thephase, the are released to perform work on

the next phase


17/18


Barriers


18/18


Quiz Time!

Questions?

Documents

13ST - Inter Process Communication Pt III