InterprocessCommunication Handout

7/28/2019 InterprocessCommunication Handout

1/24

Interprocess Communication

Semaphores, Monitors, Channel, Rendezvous

Ingo Sander

Royal Institute of TechnologyStockholm, Sweden

[email protected]

Ingo Sander (KTH) Interprocess Communication 1 / 48

Outline1 Concurrent Process Model

2 SemaphoresDefinitionCritical Section Problem

Producer-Consumer Problem3 Monitors

DefinitionCritical Section ProblemProducer-Consumer ProblemReader-Writer Problem

4 Synchronous and Asynchronous Communication

5 Channel

6 Rendezvous

7 Bibliography



2/24

Concurrent Process Model

Modelling of Embedded Systems

Embedded systems are inherently parallel

Difficult to describe parallel behaviour in a sequential program

Idea: Encapsulate sequential programs into parallel processes

Base for many operating systems and programming languagesBase for hardware description languages



Concurrent Processes

Concurrent processes help to manage complexity of embeddedsystems

multiple rates, asynchronous input, distributed activities,multiple environments

P1

P2 P3

Environment

System



3/24


Terms: Concurrent and Parallel

Terminology and the discussion on semaphores and monitors arebased on Ben-Aris textbook [BA06].

A concurrent program is a set of sequential programs that can

be executed in parallel.Here, the term process is used for a sequential program that ispart of a concurrent program and the term program is used forthis set of sequential programs (processes).

Traditionally the term parallel is used for systems, in which theexecution of several programs overlap in time by running them

on separate processors.The term concurrent is reserved for potential parallelism, in which theexecutions may, but need not, overlap.



Process States

A process can be in several states:

inactive Initial state of a process

ready Process is ready for execution, but not scheduled

running Process is executed

blocked Process is not ready for execution (lack of resources)

completed Process has executed its final statement

completedrunninginactive ready

blocked



4/24


Interprocess Communication Mechanisms

Operating systems and concurrent programming languages offerprogramming constructs for the communication between processes.In order to develop an efficient embedded system these constructs

have to be well understood.Examples

Semaphore, Mailbox, Message Queue, Event Flag, Monitor,Protected Object, Rendezvous, Channel

In this lecture we concentrate on semaphores, monitors, protected

objects, rendezvous and channels.


Semaphores Definition

Semaphores

A semaphore S can be viewed as a record with two fields.

S.V A non-negative integerS.L A set of processes

A semaphore is initialized with a value k 0 for S.V and withthe empty set for S.L.

A process p can use two statements that are defined on asemaphore: wait(S) and signal(S)1.

A semaphore, where S.V can take arbitrary non-negative valuesis called general semaphore, a semaphore, where S.V can onlytake the values 0 and 1 is called binary semaphore.

1Originally Dijkstra used P(S) for wait(S) and V(S) for signal(S).MicroC/OS-II has the corresponding functions OSSemPend() and OSSemPost().



5/24

Semaphores Definition

wait(S) and signal(S)wait(S)

if S.V > 0 thenS.V S.V 1

else

S.L S.L pp.state blocked

end if

If the value of S.V is

zero, the process p is blockedand is added to the set ofprocesses waiting for S. The

process p is blocked on thesemaphore S.

non-zero, decrement S.V. Theprocess p continues execution.

signal(S)

if S.L = thenS.V S.V + 1

else

S.L S.L {q}q.state ready

end if

If S.L is

empty, increment the value ofS.V

not empty, unblock anarbitrary process q in thewaiting list S.L. The process qis unblocked and is put intothe state ready.


Semaphores Critical Section Problem

Critical Section Problem

Problem definition

Each of N processes is executing in an infinite loop a sequenceof statements that can be divided into two subsequences

the critical section

the non-critical section.

The following properties shall be fulfilled

Mutual exclusion Statements from the critical section of two ormore processes must not be interleaved

Freedom from deadlock If one or more processes are trying toenter their critical section, then one of them must

eventually succeedFreedom from (individual) starvation If any processes tries toenter the critical section, then that process musteventually succeed



6/24

Semaphores Critical Section Problem

Semaphores: Critical Section Problem

The critical section problem is difficult to solve on a baremachine without support for interprocess communicationmechanisms.

The critical section problem for two processes can be solved witha binary semaphore S that is initialized to S = {1, }.

P1 P2loop forever loop forever

non-critical section non-critical section

wait(S) wait(S)

critical section critical sectionsignal(S) signal(S)


Semaphores Producer-Consumer Problem

Producer-Consumer Problem (1/2)

Communication

Channel

P1

Pm

C1

Cn

ConsumerProcessesProcesses

Producer

Producers A producer process executes a statement produce tocreate a data element and then sends this element to

the consumer processes.Consumers Upon receipt of a data element from the producer

processes, a consumer executes a statement consumewith the data element as parameter.



7/24


Producer-Consumer Problem (2/2)

Communication

Channel

P1

Pm

C1

Cn


Producer

For asynchronous communication the channel is implemented bymeans of a buffered channel. There are two synchronization issues:

Consumer cannot take data element from an empty buffer

Producer cannot write data element into a full buffer



Semaphores: Producer-Consumer Problem (1/2)For a bounded channel buffer the producer consumer problem can besolved with a pair of general semaphores.

Producer Consumer

loop forever loop forever

d produce wait(notEmpty)wait(notFull) d take(buffer)append(d, buffer) signal(notFull)

signal(notEmpty) consume(d)

Initially,

the buffer of size N is emptythe semaphore notEmpty = (0, )

the semaphore notFull = (N, )



8/24


Semaphores: Producer-Consumer Problem (2/2)

Buffered

Channel

P1

Pm

C1

Cn


Producer

notFull

notEmpty

signalwait

Initially,the buffer of size N is empty

the semaphore notEmpty is notEmpty = (0, )

the semaphore notFull is notFull = (N, )Ingo Sander (KTH) Interprocess Communication 15 / 48


Weak and Strong Semaphores

The semaphore we have discussed so far used is called a weaksemaphore.

A strong semaphore is defined as follows:

wait(S)

if S.V > 0 thenS.V S.V 1

else

S.L append(S.L,p)p.state blocked

end if

signal(S)

if S.L = thenS.V S.V + 1

else

q head(S.L)S.L tail(S.L)q.state ready

end if

This ensures that a process will eventually be unblocked, if it is in thewaiting list of the semaphore S.

head returns first element of a list

tail returns all but first element of a listIngo Sander (KTH) Interprocess Communication 16 / 48


9/24


10/24

Monitors Critical Section Problem

Monitor: Critical Section Problem (1/3)

The following monitor ensures that the function swap can only beexecuted by one process.

monitor CriticalSection-- Definition of data types

integer n 0

operation swap(x)

-- Definition of swap

integer temp

temp xx nn temp

The operation swap is executed atomicly.




P1 P2loop forever loop forever

CriticalSection.swap(x) CriticalSection.swap(y)

Non-critical section Non-critical section

Thanks to the monitor it is ensured that not more than oneprocessor enters the critical section.

Starvation is still possible, since no explicit queue is associatedwith the monitor.



11/24



monitor CriticalSection

n 0

A process must open the lock to the monitor. The process enters themonitor and the door is directly locked. When the process leaves themonitor the door is unlocked.



Explicit Synchronization

A monitor implicitly ensures mutual exclusion to its variables,but often explicit synchronization as in the producer-consumerproblem is required in addition

Two options to provide synchronization in monitors

1 The required condition is named by a condition variable (event).Classical monitor uses this approach.

Boolean expressions are used to test the condition, blocking onthe condition variable when necessaryA separate statement unblocks the process when the conditioncomes true

2 The alternate approach blocks directly on the expression andlets the implementation unblock a process when the condition istrue. Approach is used by protected objects.



12/24


Simulating Semaphores with Monitor (1/2)

monitor Sem

integer s k

condition notZero

operation waiti f s = 0

waitC(notZero)

s s - 1

operation signal

s s + 1

signalC(notZero)

P1 P2


Non-critical section Non-critical sectionSem.wait Sem.wait

Critical section Critical section

Sem.signal Sem.signal



Simulating Semaphores with Monitor (2/2)

s 0

notZeromonitor Sem



13/24


waitC and signalC

waitC(cond)

append p to cond

p.state blocked

monitor.lock release

signalC(cond)

if cond = empty thenremove head of cond and

assign to q

q.state readyend if

For each condition variable there is an associated FIFO queueof blocked processes

waitC and signalC are atomic functions

A process executing waitC blocks unconditionally, since we

assume that we have checked the condition in a precedingif-statement

When a process executes signalC the next process q in thewaiting list for cond is unblocked


Monitors Producer-Consumer Problem

Monitor: Producer-Consumer Problem (1/4)

The producer-consumer problem with finite buffer can be solvedusing a monitor and two condition variables notEmpty and notFull.

monitor PC

bufferType buffer empty

condition notEmpty

condition notFull

operation append (datatype v)

if buffer is full

waitC(notFull)

append(v, buffer)

signalC(notEmpty)

operation take()

datatype w

if buffer is emptywaitC(notEmpty)

w head(buffer)

signalC(notFull)

return w



14/24



The producer and consumer can now communicate without knowingdetails about the data structure of the finite buffer.

Producer Consumer

datatype d datatype d


d produce d PC.takePC.append(d) consume(d)




If signal(cond) is executed the first process in the queue for condis unblocked.

This can result in an invalid state, since

the signaling process p can continue to execute the next

statement after signalC(cond)

the unblocked process q can continue to execute the nextstatement after waitC(cond)

Thus two processes would execute inside the monitor, but thisviolates the mutual exclusion requirement.

Precedence between signaling and waiting processes has to be

defined, so that only one process can execute inside the monitor.



15/24


Monitor: Process States

Processes inside the monitor can be in different states:

Monitorbeen released

Queue of processes, where

wait condition has just

Queue of processes, which

have just completed a

signaling operation

Processes that are blocked

on condition B

Processes that are blocked

on condition A

(E)

(E)

(W)

(S)



Monitor: Immediate Resumption Requirement

The immediate resumption requirement (or signal and urgent wait)specifies one meaningful precedence between

signaling processes (S)

waiting processes (W)

processes that are blocked on the entry (E)

One meaningful priority order is E < S < W.

It means that when a blocked process on a condition variable issignaled, it immediately begins execution ahead of the signalingprocess. At that moment the condition the waiting process was

waiting for holds and no extra checking needs to be done. If thesignaling process would be run, it might modify the state of theprogram, so that the condition again becomes false.



16/24

Monitors Reader-Writer Problem

Reader-Writer Problem

The problem of readers and writers is similar to the critical sectionproblem. But here simultaneous read accesses are allowed.

Readers Processes which are required to exclude writers but not

other readers

Writers Processes which are required to exclude both readersand other writers

The reader-writer problem is an abstraction of access to database,and can be used to model the access to a shared memory.



Monitor: Reader-Writer Problem (1/2)

Reader Writer

RW.StartRead RW.StartWrite

read database write database

RW.EndRead RW.EndWrite

The monitor solution uses four variables:readers number of readers currently reading the database

writers number of writers currently writing to the database

OKtoRead A condition variable for blocking readers until it is OKto read

OKtoWrite A condition variable for blocking writers until it is OKto write



17/24


Monitor: Reader-Writer Problem (2/2)

monitor RW

integer readers 0integer writers 0

condition OKtoRead, OKtoWrite

operation StartRead operation StartWrite

if writers = 0 or not empty(OKtoWrite) if writers = 0 or readers = 0waitC(OKtoRead) waitC(OKtoWrite)

readers readers + 1 writers writers + 1signalC(OKtoRead)

operation EndRead operation EndWrite

readers readers - 1 writers writers - 1

if readers = 0 if empty(OKtoRead)signalC(OKtoWrite) then signalC(OKtoWrite)

else signalC(OKtoRead)

The first blocked writer has precedence over waiting readers!



Protected Objects (1/2)

The protected object simplifies the programming of monitors byencapsulating the manipulation of the queues together with theevaluation of expressions.

Synchronization is performed upon entry to and exit from an

operation.An operation may have a when operation called a barrier

The operation may only start if the barrier is trueIf the barrier is false the process is blocked on a FIFO queueassociated with the entry

When execution of an operation has been completed, all barriers

are re-evaluatedIf one of them is true, the process at the head of the FIFOqueue associated with that barrier is unblocked



18/24


Protected Objects (2/2)

protected object RW

integer readers 0

boolean writing false

operation StartRead when not writingreaders readers + 1

operation EndRead

readers readers - 1

operation StartWrite when not writing and readers = 0

writing true

operation EndWrite

writing falseReader WriterRW.StartRead RW.StartWrite

read database write database

RW.EndRead RW.EndWrite



Summary

Monitors ensure mutual exclusion and provide a structured formof synchronization and fit well to an object-oriented style ofprogramming

Communication is based on sharing of data



19/24

Synchronous and Asynchronous Communication

Synchronous CommunicationExchange of message is an atomic reaction that requires participation ofthe sending process, the sender, and the receiving process, the receiver.

If the sender is ready to send, but the receiver is not ready to receive,the sender is blocked.

If the receiver is ready to receive, but the sender is not ready to send,the receiver is blocked.

An example for synchronous communication is a telephone call.

The term synchronous is used in a different way in synchronoushardware design, but also in the context of synchronous languages, likeLustre or Esterel.



Asynchronous Communication

There is no temporal dependence between the sending of themessage and the receiving of a message.

The sender can send a message and continue independent of thestate of the receiver.

The receiver can receive a message and continue independent ofthe state of the sender.

An example for asynchronous communication is e-mail.



20/24


Synchronous vs Asynchronous Communication

Both synchronous and asynchronous communication have theiradvantages.

Asynchronous communication does not block sender or receiver,

if there counterpart is not ready.

Asynchronous communication requires a buffer to storemessages that are sent, but not yet received.


Channel

Synchronous Channel

A channel connects a sending process with a receiving process. Asynchronous channel implies that a value v that is sent on a channelch is directly received by the receiver. Thus both sender and receiverhave to be ready to conduct a communication over a channel. A

channel carries values of a given type.

P Channel C



21/24

Channel

Channel: Producer-Consumer Problem

P Channel C

Producer Consumer

integer x integer y


x produce ch ych x consume(y)


Channel

Discussion

Channels are easy and efficient to use.

Channels lack flexibility, since they have to export a fixed set ofchannels at compile time.

Difficult to model a client-server application, where the number

of clients is unknown at compile-time.



22/24

Rendezvous

Rendezvous (1/2)

In a rendezvous two processes meet and synchronize for a shortmoment of time.It uses two kind of processes:

Calling Process The calling process must know the identity of theaccepting process and the identity of the rendezvous (anentry).

Accepting Process The location of the rendezvous belongs to theaccepting process. The accepting process does not needto know the identity of the calling process.


Rendezvous

Rendezvous (2/2)

1 A calling process calls an entry of the accepting process. Itblocks until the accepting process is ready to accept the call.

2 During the rendezvous, the accepting process produces a resultusing parameters that have been provided by the caller.

3 At the completion of the rendezvous, the calling process receivesthe result and is unlocked.

Rendezvous is very well suited for client-server applications.



23/24

Rendezvous

Rendezvous: Client-Server Application

Client Server

integer param, result integer param, result


param . . .Server.req(param, result) accept req (param, result)

use(result) result serve request(param

There can be any number of clients. The server does not need to beaware of the identity or number of clients.


Rendezvous

Communication and Synchronization during a

Rendezvous

accept Request

Server

Server.Request

Client 1

Parameters

Resultsend

Server.Request

Client 2

accept RequestParameters

Resultsend

Time



24/24

Rendezvous

Discussion

A rendezvous requires a synchronization between a calling and acalled process. Both processes need to arrive at a certainstatement to proceed.

The rendezvous is a perfect vehicle to implement client-serverapplications, since the server does not to be aware of thenumber and identity of possible clients.


Bibliography

Bibliography

Mordechai Ben-Ari.Principles of Concurrent and Distributed Programming.Addison-Wesley, 2006.

Date post:	03-Apr-2018
Category:	Documents
Upload:	bittronic
View:	220 times
Download:	0 times

InterprocessCommunication Handout

Documents