InterprocessCommunication Handout
Transcript of InterprocessCommunication Handout
-
7/28/2019 InterprocessCommunication Handout
1/24
Interprocess Communication
Semaphores, Monitors, Channel, Rendezvous
Ingo Sander
Royal Institute of TechnologyStockholm, Sweden
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
Ingo Sander (KTH) Interprocess Communication 2 / 48
-
7/28/2019 InterprocessCommunication Handout
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
Ingo Sander (KTH) Interprocess Communication 3 / 48
Concurrent Process Model
Concurrent Processes
Concurrent processes help to manage complexity of embeddedsystems
multiple rates, asynchronous input, distributed activities,multiple environments
P1
P2 P3
Environment
System
Ingo Sander (KTH) Interprocess Communication 4 / 48
-
7/28/2019 InterprocessCommunication Handout
3/24
Concurrent Process Model
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.
Ingo Sander (KTH) Interprocess Communication 5 / 48
Concurrent Process Model
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
Ingo Sander (KTH) Interprocess Communication 6 / 48
-
7/28/2019 InterprocessCommunication Handout
4/24
Concurrent Process Model
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.
Ingo Sander (KTH) Interprocess Communication 7 / 48
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().
Ingo Sander (KTH) Interprocess Communication 8 / 48
-
7/28/2019 InterprocessCommunication Handout
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.
Ingo Sander (KTH) Interprocess Communication 9 / 48
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
Ingo Sander (KTH) Interprocess Communication 10 / 48
-
7/28/2019 InterprocessCommunication Handout
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)
Ingo Sander (KTH) Interprocess Communication 11 / 48
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.
Ingo Sander (KTH) Interprocess Communication 12 / 48
-
7/28/2019 InterprocessCommunication Handout
7/24
Semaphores Producer-Consumer Problem
Producer-Consumer Problem (2/2)
Communication
Channel
P1
Pm
C1
Cn
ConsumerProcessesProcesses
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
Ingo Sander (KTH) Interprocess Communication 13 / 48
Semaphores Producer-Consumer Problem
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, )
Ingo Sander (KTH) Interprocess Communication 14 / 48
-
7/28/2019 InterprocessCommunication Handout
8/24
Semaphores Producer-Consumer Problem
Semaphores: Producer-Consumer Problem (2/2)
Buffered
Channel
P1
Pm
C1
Cn
ConsumerProcessesProcesses
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
Semaphores Producer-Consumer Problem
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
-
7/28/2019 InterprocessCommunication Handout
9/24
-
7/28/2019 InterprocessCommunication Handout
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.
Ingo Sander (KTH) Interprocess Communication 19 / 48
Monitors Critical Section Problem
Monitor: Critical Section Problem (2/3)
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.
Ingo Sander (KTH) Interprocess Communication 20 / 48
-
7/28/2019 InterprocessCommunication Handout
11/24
Monitors Critical Section Problem
Monitor: Critical Section Problem (3/3)
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.
Ingo Sander (KTH) Interprocess Communication 21 / 48
Monitors Critical Section Problem
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.
Ingo Sander (KTH) Interprocess Communication 22 / 48
-
7/28/2019 InterprocessCommunication Handout
12/24
Monitors Critical Section Problem
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
loop forever loop forever
Non-critical section Non-critical sectionSem.wait Sem.wait
Critical section Critical section
Sem.signal Sem.signal
Ingo Sander (KTH) Interprocess Communication 23 / 48
Monitors Critical Section Problem
Simulating Semaphores with Monitor (2/2)
s 0
notZeromonitor Sem
Ingo Sander (KTH) Interprocess Communication 24 / 48
-
7/28/2019 InterprocessCommunication Handout
13/24
Monitors Critical Section Problem
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
Ingo Sander (KTH) Interprocess Communication 25 / 48
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
Ingo Sander (KTH) Interprocess Communication 26 / 48
-
7/28/2019 InterprocessCommunication Handout
14/24
Monitors Producer-Consumer Problem
Monitor: Producer-Consumer Problem (2/4)
The producer and consumer can now communicate without knowingdetails about the data structure of the finite buffer.
Producer Consumer
datatype d datatype d
loop forever loop forever
d produce d PC.takePC.append(d) consume(d)
Ingo Sander (KTH) Interprocess Communication 27 / 48
Monitors Producer-Consumer Problem
Monitor: Producer-Consumer Problem (3/4)
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.
Ingo Sander (KTH) Interprocess Communication 28 / 48
-
7/28/2019 InterprocessCommunication Handout
15/24
Monitors Producer-Consumer Problem
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)
Ingo Sander (KTH) Interprocess Communication 29 / 48
Monitors Producer-Consumer Problem
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.
Ingo Sander (KTH) Interprocess Communication 30 / 48
-
7/28/2019 InterprocessCommunication Handout
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.
Ingo Sander (KTH) Interprocess Communication 31 / 48
Monitors Reader-Writer Problem
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
Ingo Sander (KTH) Interprocess Communication 32 / 48
-
7/28/2019 InterprocessCommunication Handout
17/24
Monitors Reader-Writer Problem
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!
Ingo Sander (KTH) Interprocess Communication 33 / 48
Monitors Reader-Writer Problem
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
Ingo Sander (KTH) Interprocess Communication 34 / 48
-
7/28/2019 InterprocessCommunication Handout
18/24
Monitors Reader-Writer Problem
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
Ingo Sander (KTH) Interprocess Communication 35 / 48
Monitors Reader-Writer Problem
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
Ingo Sander (KTH) Interprocess Communication 36 / 48
-
7/28/2019 InterprocessCommunication Handout
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.
Ingo Sander (KTH) Interprocess Communication 37 / 48
Synchronous and Asynchronous Communication
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.
Ingo Sander (KTH) Interprocess Communication 38 / 48
-
7/28/2019 InterprocessCommunication Handout
20/24
Synchronous and Asynchronous Communication
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.
Ingo Sander (KTH) Interprocess Communication 39 / 48
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
Ingo Sander (KTH) Interprocess Communication 40 / 48
-
7/28/2019 InterprocessCommunication Handout
21/24
Channel
Channel: Producer-Consumer Problem
P Channel C
Producer Consumer
integer x integer y
loop forever loop forever
x produce ch ych x consume(y)
Ingo Sander (KTH) Interprocess Communication 41 / 48
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.
Ingo Sander (KTH) Interprocess Communication 42 / 48
-
7/28/2019 InterprocessCommunication Handout
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.
Ingo Sander (KTH) Interprocess Communication 43 / 48
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.
Ingo Sander (KTH) Interprocess Communication 44 / 48
-
7/28/2019 InterprocessCommunication Handout
23/24
Rendezvous
Rendezvous: Client-Server Application
Client Server
integer param, result integer param, result
loop forever loop forever
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.
Ingo Sander (KTH) Interprocess Communication 45 / 48
Rendezvous
Communication and Synchronization during a
Rendezvous
accept Request
Server
Server.Request
Client 1
Parameters
Resultsend
Server.Request
Client 2
accept RequestParameters
Resultsend
Time
Ingo Sander (KTH) Interprocess Communication 46 / 48
-
7/28/2019 InterprocessCommunication Handout
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.
Ingo Sander (KTH) Interprocess Communication 47 / 48
Bibliography
Bibliography
Mordechai Ben-Ari.Principles of Concurrent and Distributed Programming.Addison-Wesley, 2006.