Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
T�106.4155 Operating Systems:Concurrency I
Timo Lilja
September 19, 20121
1$Id: lecture-3.tex 238 2012-09-14 10:12:07Z tlilja $Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 1 / 67
Mutual Exclusion and Synchronization
1 Mutual Exclusion and SynchronizationPrinciples of ConcurrencyMutual ExclusionSemaphoresMonitorsMessage PassingReaders/Writers Problem
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 2 / 67
Mutual Exclusion and Synchronization Principles of Concurrency
1 Mutual Exclusion and SynchronizationPrinciples of ConcurrencyMutual ExclusionSemaphoresMonitorsMessage PassingReaders/Writers Problem
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 3 / 67
Mutual Exclusion and Synchronization Principles of Concurrency
Principles of Concurrency
In uniprocessor systems processes may be interleaved
In multiprocessor systems processes can be interleaved or overlapped
Di�culties of concurrency
sharing global resourcesoptimally allocating system resources�nding programming errors is di�cult since the results arenondeterministic and irreproducible
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 4 / 67
Mutual Exclusion and Synchronization Principles of Concurrency
An Example
Consider a simple example
void echo()
chin = getchar();
chout = chin;
putchar(chout);
Interleaved execution on a multiprocessor system, the same line takesplace in parallel
P1: P2:
chin = getchar();
chin = getchar();
chout = chin; chout = chin;
putchar(chout);
putchar(chout);
The character input on P1 is lost and P2's input is displayed by bothprocesses
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 5 / 67
Mutual Exclusion and Synchronization Principles of Concurrency
Enforcing single access
if we allow only one process to enter the echo process, we avoid thenondeterministic behavior
P1 and P2 run on separate processes
P1 enters echo �rst
P2 tries to enter but it is blocked
P1 completes execution
P2 resumes and executes echo
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 6 / 67
Mutual Exclusion and Synchronization Principles of Concurrency
Race Condition
Race condition occurs when multiple processes read or write dataitems so that the �nal result depends on the order of execution of theprocesses
An example
Consider two processes P1 and P2 that share a global variable aP1 updates a to the value 1P2 updates a to the value 2Tasks P1 and P2 are in race with write variable athe �loser� of the race (here P2) determines the �nal value
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 7 / 67
Mutual Exclusion and Synchronization Principles of Concurrency
Competition among Processes for Resources
Two processes are in con�ict when they compete for the same resource
Other process may slow down if it has to wait for the resource
Critical resource is the resource that is used by competing processes,the code that uses the resource is critical section
Control problems
deadlockstarvation
Mutual exclusion
no two processes can enter the critical section at the same time
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 8 / 67
Mutual Exclusion and Synchronization Principles of Concurrency
Deadlock
Given two process P1 and P2 and two resources R1 and R2
Both resources are needed by the processes in order to proceed
OS assigns R1 to P1 and R2 to P2
Both processes are waiting for the other resources and cannot proceed
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 9 / 67
Mutual Exclusion and Synchronization Principles of Concurrency
Starvation
Three processes P1, P2 and P3 require periodic access to R
P1 is in possession of the resource R
P1 is completed and OS schedules P3 to be executed next
After P3 OS schedules P1 again
P2 is starving, since it doesn't get executed at all
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 10 / 67
Mutual Exclusion and Synchronization Mutual Exclusion
1 Mutual Exclusion and SynchronizationPrinciples of ConcurrencyMutual ExclusionSemaphoresMonitorsMessage PassingReaders/Writers Problem
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 11 / 67
Mutual Exclusion and Synchronization Mutual Exclusion
Mutual Exclusion (1/2)
Requirements
must be enforced: only one process allowed to enter the critical section
a process that halts in non-critical section must do so withoutinterfering with other processes
process must not be delayed inde�nitely when requiring access tocritical section (no starvation or deadlock)
when no process is in CS, any process must be permitted to enterwithout delay
no assumptions about relative process speeds or number of processors
process must remain in CS for a �nite time only
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 12 / 67
Mutual Exclusion and Synchronization Mutual Exclusion
Mutual Exclusion (2/2)
there are n processes to be executed concurrentlyeach process operate on some resource Rato enforce mutual exclusion functions entercritical andexitcritical are providedthe functions take the resource to be controlled as an argument
PROCESS 1 */ void P1 { while (true) { /* preceding code */; entercritical (Ra); /* critical section */; exitcritical (Ra); /* following code */; } }
/* PROCESS 2 */ void P2 { while (true) { /* preceding code */; entercritical (Ra); /* critical section */; exitcritical (Ra); /* following code */; } }
• • •
/* PROCESS n */ void Pn { while (true) { /* preceding code */; entercritical (Ra); /* critical section */; exitcritical (Ra); /* following code */; } }
Figure 5.1 Illustration of Mutual Exclusion
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 13 / 67
Mutual Exclusion and Synchronization Mutual Exclusion
Mutual Exclusion: Uniprocessor System Solution
In uniprocessor system, executions cannot overlap
Only interleaving is possible
A process continues to run until an interrupt or system call is invoked
Thus, to guarantee mutual exclusion, it is enough to disable interrupts
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 14 / 67
Mutual Exclusion and Synchronization Mutual Exclusion
Mutual Exclusion: Multiprocessor System Solution
In multiprocessor system, the execution is concurrent
Processors share access to common main memory
There is no interrupt mechanism between processors
Access to a single memory location is atomic
if two processes try to access same memory location, one of them isblocked
Mutex is achieved by revising machine instructions that perform twooperations atomically
reading and writing a memory addressreading and testing a memory address
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 15 / 67
Mutual Exclusion and Synchronization Mutual Exclusion
Mutual Exclusion: Hardware Support
compare and swapint compare_and_swap(int *word, int testval, int newval){
int oldval;oldval = *word;if (oldval == testval) *word = newval;return oldval;
}
exchangeint exchange (int register, int memory){
int temptemp = memory;memory = register;register = temp;
}
Even that code is C, it is executed atomically in a single instruction ona real CPU (e.g. x86 has XCHG instruction)
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 16 / 67
Mutual Exclusion and Synchronization Mutual Exclusion
Mutual Exclusion: Protocol
/* program mutualexclusion */ const int n = /* number of processes */; int bolt; void P(int i) { while (true) { while (compare_and_swap(bolt, 0, 1) == 1) /* do nothing */; /* critical section */; bolt = 0; /* remainder */; } } void main() { bolt = 0; parbegin (P(1), P(2), . . . ,P(n)); }
/* program mutualexclusion */ int const n = /* number of processes**/; int bolt; void P(int i) { int keyi = 1; while (true) { do exchange (keyi, bolt) while (keyi != 0); /* critical section */; bolt = 0; /* remainder */; } } void main() { bolt = 0; parbegin (P(1), P(2), . . ., P(n)); }
(a) Compare and swap instruction (b) Exchange instruction
Figure 5.2 Hardware Support for Mutual Exclusion
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 17 / 67
Mutual Exclusion and Synchronization Mutual Exclusion
Mutual Exclusion: Summary
Pros
applicable to any number of processorssimple and easy to verifycan support multiple critical sections
Cons
uses busy waiting which consumes CPU timestarvation is possible: no guarantees that all processes get their chanceto run once the resource is freedeadlock is possible
two processes P1 and P2 using same resource, P2 with higher priority
P1 executes compare-and-swap
P1 is interrupted and processor is given to higher priority P2 process
P2 ends up waiting for the resource in a busy loop
P1 won't get executed since P2 has higher priority
We need to devise some other mechanism to guarantee mutualexclusion at least for user level programs
but are there cases where spinlocks in userland are applicable?
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 18 / 67
Mutual Exclusion and Synchronization Semaphores
1 Mutual Exclusion and SynchronizationPrinciples of ConcurrencyMutual ExclusionSemaphoresMonitorsMessage PassingReaders/Writers Problem
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 19 / 67
Mutual Exclusion and Synchronization Semaphores
Semaphores (1/2)
An integer value used for signalling among processes
Three operations
initialize(S, n)
initialize semaphore S value to a given number nn indicates the number of processes allowed concurrently enter thesynchronized section
semWait(S)
decrement the semaphore value by 1if the value becomes negative ⇒ block
semSignal(S)
increment the semaphore value by 1wakeup a sleeping process if the pre-increment value was < 0
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 20 / 67
Mutual Exclusion and Synchronization Semaphores
Semaphores (2/2)
Consequences
no way to know whether process decrementing a semaphore will blockafter incrementing a semaphore both incrementing and possibly wakenprocess continue to run
there is no way to know which will be run next
no way to know if another process is waiting
number ow woken processes may be zero or one
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 21 / 67
Mutual Exclusion and Synchronization Semaphores
Semaphore Variants
Binary semaphore
can only have values 0 or 1semaphore can be locked by one process and released by another whilea mutex cannot ⇒ not the same as mutexeasier to implement but same expressive power than general semaphore
General or counting semaphore
can be initialized to any non-negative value
Strong Semaphore
order of removal is speci�ede.g. processes blocked in the wait queue for the semaphore areremoved in �rst-in-�rst-out (FIFO) order
Weak semaphore
order of removal is not speci�ed
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 22 / 67
Mutual Exclusion and Synchronization Semaphores
Binary Semaphore De�nition
struct binary_semaphore { enum {zero, one} value; queueType queue; }; void semWaitB(binary_semaphore s) { if (s.value == one) s.value = zero; else { /* place this process in s.queue */; /* block this process */; } } void semSignalB(semaphore s) { if (s.queue is empty()) s.value = one; else { /* remove a process P from s.queue */; /* place process P on ready list */; } }
Figure 5.4 A Definition of Binary Semaphore Primitives
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 23 / 67
Mutual Exclusion and Synchronization Semaphores
General Semaphore De�nition
struct semaphore { int count; queueType queue; }; void semWait(semaphore s) { s.count--; if (s.count < 0) { /* place this process in s.queue */; /* block this process */; } } void semSignal(semaphore s) { s.count++; if (s.count <= 0) { /* remove a process P from s.queue */; /* place process P on ready list */; } }
Figure 5.3 A Definition of Semaphore Primitives
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 24 / 67
Mutual Exclusion and Synchronization Semaphores
Example of Semaphore Mechanism (1/3)
Assume four processes A, B, C and D and a single semaphore s
Processes A, B, C depend on the result of D
1 A is running, s = 1, indicating that one of the results of D is available,A issues semWait (s = 0), A can continue
2 B issues semWait (s = -1), B is blocked
3 D issues semSignal (s = 0), B moves to ready queue
4 D moves to ready queue, C begins to run
5 C issues semWait (s = -1) and gets blocked, similarlyrunning A (s = -2) and B (s = -3) gets them blocked
6 D issues semSignal (s = -2) and transfers C to ready queue
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 25 / 67
Mutual Exclusion and Synchronization Semaphores
Example of Semaphore Mechanism (2/3)
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 26 / 67
Mutual Exclusion and Synchronization Semaphores
Example of Semaphore Mechanism (3/3)
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 27 / 67
Mutual Exclusion and Synchronization Semaphores
Implementation of Semaphores (1/2)
semWait and semSignal must be implemented as atomic primitives
Hardware ⇒ usually not available
Pure software (like Dekker's algorithm) ⇒ overhead
must have sequential access to memorysee the Appendix A in the book
Hardware-supported schemes: compare & swap or test & set
Uniprocessor: disable interrupts
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 28 / 67
Mutual Exclusion and Synchronization Semaphores
Implementation of Semaphores (2/2)
semWait(s) { while (compare_and_swap(s.flag, 0 , 1) == 1) /* do nothing */; s.count--; if (s.count < 0) { /* place this process in s.queue*/; /* block this process (must also set s.flag to 0) */; } s.flag = 0; } semSignal(s) { while (compare_and_swap(s.flag, 0 , 1) == 1) /* do nothing */; s.count++; if (s.count <= 0) { /* remove a process P from s.queue */; /* place process P on ready list */; } s.flag = 0; }
semWait(s) { inhibit interrupts; s.count--; if (s.count < 0) { /* place this process in s.queue */; /* block this process and allow interrupts */; } else allow interrupts; } semSignal(s) { inhibit interrupts; s.count++; if (s.count <= 0) { /* remove a process P from s.queue */; /* place process P on ready list */; } allow interrupts; }
(a) Compare and Swap Instruction (b) Interrupts
Figure 5.14 Two Possible Implementations of Semaphores
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 29 / 67
Mutual Exclusion and Synchronization Semaphores
Mutual Exclusion using Semaphores (1/3)
Assume N processes that need access to the same resource in CS
Semaphore s initialized to 1
semWait(s) is executed before entering the critical section
if s = 1 the value s is decremented and process enters CSbecause s ≤ 0, no other process can enter CS
Any number of processes may try to enter CS but will block anddecrement the value of the semaphore s
Once the process in the CS departs, it increments s
one of the blocked processes (if any) is removed from the ready queue
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 30 / 67
Mutual Exclusion and Synchronization Semaphores
Mutual Exclusion using Semaphores (2/3)
What happens if we initialize s to some other positive value than 1?
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 31 / 67
Mutual Exclusion and Synchronization Semaphores
Mutual Exclusion using Semaphores (3/3)
The value of s.count can be interpreted
s.count ≥ 0: number of processes that execute semWait(s) withoutsuspension
allows semaphores support both synchronization and mutual exclusion
s.count < 0: number of processes suspended on s.queue. I.e., numberof processes waiting access for the critical section
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 32 / 67
Mutual Exclusion and Synchronization Semaphores
The Producer/Consumer Problem
A shared bu�er in the memory
One or more producers generating data and adding it the bu�er
Single consumer taking data from the bu�er
Synchronization problem
only one process can access the bu�er at a timeconsumer won't remove data from an empty bu�er
Variations for both in�nite and �nite bu�er
in �nite bu�er, producer can't write if the bu�er is full
producer: consumer:while (true) { while (true) {
/* produce item v */ while (in <= out)b[in] = v; /* do nothing */in++; w = b[out];
} out++;/* consume item w */
}
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 33 / 67
Mutual Exclusion and Synchronization Semaphores
In�nite P/C Solution Using General Semaphores (1/2)
Semaphore(s) protecting access to functions updating bu�ersappend() and take(), initialized to 1 indicating that one ofproducer/consumers should be able to enter CS
Semaphore(n) allowing producer to signal consumer when the bu�erhas data available for reading, initialized to 0 indicating that no datais initially available in the bu�er
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 34 / 67
Mutual Exclusion and Synchronization Semaphores
In�nite P/C Solution Using General Semaphores (2/2)
/* program producerconsumer */ semaphore n = 0, s = 1; void producer() { while (true) { produce(); semWait(s); append(); semSignal(s); semSignal(n); } } void consumer() { while (true) { semWait(n); semWait(s); take(); semSignal(s); consume(); } } void main() { parbegin (producer, consumer); }
Figure 5.11 A Solution to the Infinite-Buffer Producer/Consumer Problem
Using Semaphores
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 35 / 67
Mutual Exclusion and Synchronization Monitors
1 Mutual Exclusion and SynchronizationPrinciples of ConcurrencyMutual ExclusionSemaphoresMonitorsMessage PassingReaders/Writers Problem
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 36 / 67
Mutual Exclusion and Synchronization Monitors
Monitors
With semaphores it is di�cult to write a correct program becausesemaphore operations are scattered throughout the program
A monitor is a synchronization construct that provides equivalentfunctionality
monitors consist of one ore more procedures,initialization sequence and local datalocal data is accessible only by the monitor's proceduresa process enters the monitor by invoking one of its processesonly one process may be executing the monitor at a time
Monitors support synchronization primitive called condition variables
cwait(c) suspend the execution of the process on condition c.The monitor can be used by other processescsignal(c) resume the execution of the blocked process after a cwait(c).If there are several processes choose one, if there are none, do nothing
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 37 / 67
Mutual Exclusion and Synchronization Monitors
Structure of a Monitor
Entrance
queue ofentering
processes
Exit
condition c1
cwait(c1)
urgent queue
csignal
condition cn
cwait(cn)
local data
condition variables
Procedure 1
Procedure k
initialization code
Figure 5.15 Structure of a Monitor
monitor waiting area
MONITOR
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 38 / 67
Mutual Exclusion and Synchronization Monitors
Bounded-bu�er P/C Using a Monitor (1/3)
Two condition variables
notfull: room to add at least one characternotempty: there is at least one character
Method append
append characters if notfull, otherwise blocksignal notempty to inform that there is a character
Method take
take characters if notemptysignal notfull once process has taken a character
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 39 / 67
Mutual Exclusion and Synchronization Monitors
Bounded-bu�er P/C Using a Monitor (2/3)
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 40 / 67
Mutual Exclusion and Synchronization Monitors
Bounded-bu�er P/C Using a Monitor (3/3)
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 41 / 67
Mutual Exclusion and Synchronization Monitors
Semaphores vs. Monitors (1/2)
With semaphores, the synchronization is scattered throughoutthe program
With monitors, the synchronization needs to be done only in monitor
which is precisely the part that handles the shared data structure
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 42 / 67
Mutual Exclusion and Synchronization Monitors
Semaphores vs. Monitors (2/2)
vs
/* program boundedbuffer */ const int sizeofbuffer = /* buffer size */; semaphore s = 1, n= 0, e= sizeofbuffer; void producer() { while (true) { produce(); semWait(e); semWait(s); append(); semSignal(s); semSignal(n); } } void consumer() { while (true) { semWait(n); semWait(s); take(); semSignal(s); semSignal(e); consume(); } } void main() { parbegin (producer, consumer); }
Figure 5.13 A Solution to the Bounded-Buffer Producer/Consumer
Problem Using Semaphores
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 43 / 67
Mutual Exclusion and Synchronization Monitors
Hoare vs. Lampson�Redell Monitors (1/3)
Hoare's (the previous) de�nition requires that if there's a process in thequeue for condition c , it runs immediately when another process issuescsignal(c)
if the process issuing csignal is not �nished with the monitor, need twocontext switches to resume computation
process scheduling must be perfectly reliable: no other process mayenter the monitor before the signaled process gets executed otherwisethe signal condition may not hold
if a producer process appends a new character to the bu�er and failsbefore signaling notempty ⇒ all processes waiting for the condition arepermanently hung
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 44 / 67
Mutual Exclusion and Synchronization Monitors
Hoare vs. Lampson�Redell Monitors (2/3)
Lampson�Redell Monitors (MESA) de�nition
replace csignal with cnotify(q): the queue q will be noti�ed but thecurrent process continues to execute
a process in the queue q will be executed at some later time
there is no guarantee that other processes won't enter the monitorbefore the process in the head of queue q
the process must check that the condition is still valid(replace if's with while loops)
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 45 / 67
Mutual Exclusion and Synchronization Monitors
Hoare vs. Lampson�Redell Monitors (3/3)
Hoare
Mesa
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 46 / 67
Mutual Exclusion and Synchronization Monitors
Lampson�Redell Monitor Advantages
Signaled process checks the condition and goes back to sleep if thecondition is not met
an incorrect signaling or broadcast does not cause erroneous behavioras it would with Hoare's monitors
Consider implementing a bu�er allocator with two levels of conditionsneeded to be satis�ed by co-operating processes
1 mutex access to the shared data structures2 enough memory for this process to complete the request
Hoare: signal implies (1) and implicitly (2)In L-R: the waiting process must check invariant (2)Thus, if programmer changes the invariant (2), heneeds to reprogram all signaling when using Hoare's monitors
Thus, Lampson�Redell monitors enforce more modular andless error prone design
but in practice libraries implement both! Why?
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 47 / 67
Mutual Exclusion and Synchronization Message Passing
1 Mutual Exclusion and SynchronizationPrinciples of ConcurrencyMutual ExclusionSemaphoresMonitorsMessage PassingReaders/Writers Problem
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 48 / 67
Mutual Exclusion and Synchronization Message Passing
Message Passing
Processes interacting between each other need to synchronize andcommunicate
In message passing a process sends a message to another processdesignated by a destination by invoking the primitive
send(destination, message)
Another process receives the message by calling
receive(source, message)
Message passing is applicable both in shared memory computers andnon-shared memory (distributed) systems
you can use message passing in shared memory systems too
A note on terminology:
programs can have concurrency in them (e.g. algorithms)parallel execution is the property of the machinein distributed computing, systems are autonomous and usually don'tshare common memory
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 49 / 67
Mutual Exclusion and Synchronization Message Passing
Synchronization
When a message has been sent the sent via send() the process canblock until the message is received or continue execution
Similarly, when a process issues receive()
the call can return immediately if there is a message waitingit can block if there are no messages waitingcan return immediately and abandon receiving the message
Combinations
blocking send/blocking receive: called rendezvous,provides tight synchronization between processesnon-blocking send/blocking receive: usual case, since a process cansend a message and do useful work but the receiving (server) processcan't do anything until a request arrivesnon-blocking send/non-blocking receive: synchronization is not verytight, applicable when both processes can do useful work without themessages
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 50 / 67
Mutual Exclusion and Synchronization Message Passing
Addressing (1/2)
Direct addressing
send primitive explicitly speci�es destinationreceive can either designate sending process or accept all connectionsand implicitly pass the senders address when returning
Indirect addressing
message not send directly between sender and receivermailbox: a queue holding the message until it is delivered
Indirect addressing allows more �exible messaging
one-to-onemany-to-oneone-to-manymany-to-many
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 51 / 67
Mutual Exclusion and Synchronization Message Passing
Addressing (2/2)
S1
Sn
R1
Rm
Mailbox
S1
Sn
R1Port
Figure 5.18 Indirect Process Communication
(b) Many to one
S1 R1Mailbox
S1
(a) One to one
(d) Many to many
R1
Rm
Mailbox
(c) One to many
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 52 / 67
Mutual Exclusion and Synchronization Message Passing
Message Formats
Objectives: single computer or distributed system?
Fixed or variable length size?
Pass-by-Reference or pass-by-value?
if a large amount of data to be transfered, send a link instead
Contents
header (type, destination addr, source addr, length, control info)body: data
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 53 / 67
Mutual Exclusion and Synchronization Message Passing
Mutual Exclusion (1/2)
Messages can be used to enforce mutual exclusion
Assuming blocking receive and non-blocking send
A set of processes share a mailbox mbox
initialized to contain null message
A process entering the CS issues receive
if the box is empty, receive blocksotherwise, it empties the box and enters critical section
Once process is �nished with CS, it puts the message back to mbox
If more than one process performs receive concurrently
message is delivered to only one process and others blockall processes are blocked if the queue is emptyone process is activated when a message arrives
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 54 / 67
Mutual Exclusion and Synchronization Message Passing
Mutual Exclusion (2/2)
/* program mutualexclusion */ const int n = /* number of processes */; void P(int i) { message msg; while (true) { receive (box, msg); /* critical section */; send (box, msg); /* remainder */; } } void main() { create_mailbox (box); send (box, null); parbegin (P(1), P(2), . . ., P(n)); }
Figure 5.20 Mutual Exclusion Using Messages
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 55 / 67
Mutual Exclusion and Synchronization Message Passing
Bounded-Bu�er Producer/Consumer (1/2)
mayconsume message
sent by the producer once the data has been generatedif there is at least one message, consumer can consumeserver as the bu�erdata organized as a queue of messages
Variable capacity determines the bu�er size
mayproduce message
initialized with number of null message indicated by variable capacitynumber of messages shrinks/increases when consumed/produced
Flexible
scales to any number of producers and consumerscan be located on di�erent machines (distributed)
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 56 / 67
Mutual Exclusion and Synchronization Message Passing
Bounded-Bu�er Producer/Consumer (2/2)
const int capacity = /* buffering capacity */ ; null = /* empty message */ ; int i; void producer() { message pmsg; while (true) { receive (mayproduce, pmsg); pmsg = produce(); send (mayconsume, pmsg); } } void consumer() { message cmsg; while (true) { receive (mayconsume, cmsg); consume (cmsg); send (mayproduce, null); } } void main() { create_mailbox (mayproduce); create_mailbox (mayconsume); for (int i = 1; i <= capacity; i++) send (mayproduce, null); parbegin (producer, consumer); }
Figure 5.21 A Solution to the Bounded-Buffer Producer/Consumer Problem
Using Messages Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 57 / 67
Mutual Exclusion and Synchronization Readers/Writers Problem
1 Mutual Exclusion and SynchronizationPrinciples of ConcurrencyMutual ExclusionSemaphoresMonitorsMessage PassingReaders/Writers Problem
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 58 / 67
Mutual Exclusion and Synchronization Readers/Writers Problem
Readers/Writers Problem
In readers/writers problem
there are a number of processes sharing a data area
there are a number of processes only reading the data
there are a number of processes only writing the data1 any number of readers can simultaneously read the data2 only one writer may write the data3 if a writer is writing the �le, no reader can read it
not the same as producer/consumer (P/C)
P is not just a writer: reads queue pointers to write next itemC is not just a reader: writes queue pointers to show it has used an item
not the same as mutual exclusion
if process do R/W access, we must use mutexR/W allows more e�cient solutions due to the fact we understandbetter how the processes share the dataConsider a library catalog: N users can read and one librarian update.Mutex would lock the system whenever there is an access to the catalog
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 59 / 67
Mutual Exclusion and Synchronization Readers/Writers Problem
Readers Have Priority (1/2)
The wsem enforces mutual exclusion between R and W
if there is one W, no other R/W can access the data
To allow multiple readers
if there is no other readers, we must wait wsemsince a writer might be activeif there are more readers, no need to wait becausewe already know that reading is OKvariable readcount: track the number of readerssemaphore x: protects access to the variable readcount
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 60 / 67
Mutual Exclusion and Synchronization Readers/Writers Problem
Readers Have Priority (2/2)
/* program readersandwriters */ int readcount; semaphore x = 1, wsem = 1; void reader() { while (true) { semWait (x); readcount++; if (readcount == 1) semWait (wsem); semSignal (x); READUNIT(); semWait (x); readcount--; if (readcount == 0) semSignal (wsem); semSignal (x); } } void writer() { while (true) { semWait (wsem); WRITEUNIT(); semSignal (wsem); } } void main() { readcount = 0; parbegin (reader, writer); }
Figure 5.22 A Solution to the Readers/Writers Problem Using
Semaphores: Readers Have Priority
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 61 / 67
Mutual Exclusion and Synchronization Readers/Writers Problem
Writers Have Priority (1/3)
Once a reader is reading, readers can retain the control inde�nitely
writers are subject to starvation
We want to guarantee that readers can't access data when there is atleast one writer wanting to write
Add the following semaphores and variables
Semaphore rsem: inhibits reads when there is at least one writer readyvariable writecount: control the setting of rsemsemaphore y: protects the variable writecount
Queue must not be allowed to build up on rsem
otherwise writers would not be able to jump the queuethus, only one reader is allowed to queue on rsemrest of the readers queue on semaphore z before queuing rsem
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 62 / 67
Mutual Exclusion and Synchronization Readers/Writers Problem
Writers Have Priority (2/3)
Table 5.6 State of the Process Queues for Program of Figure 5.23
Readers only in the system
•wsem set
•no queues
Writers only in the system
•wsem and rsem set
•writers queue on wsem
Both readers and writers with read first
•wsem set by reader
•rsem set by writer
•all writers queue on wsem
•one reader queues on rsem
•other readers queue on z
Both readers and writers with write first
•wsem set by writer
•rsem set by writer
•writers queue on wsem
•one reader queues on rsem
•other readers queue on z
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 63 / 67
Mutual Exclusion and Synchronization Readers/Writers Problem
Writers Have Priority (3/3)/* program readersandwriters */ int readcount, writecount; semaphore x = 1, y = 1, z = 1, wsem = 1, rsem = 1; void reader() { while (true) { semWait (z); semWait (rsem); semWait (x); readcount++; if (readcount == 1) semWait (wsem); semSignal (x); semSignal (rsem); semSignal (z); READUNIT(); semWait (x); readcount--; if (readcount == 0) semSignal (wsem); semSignal (x); } } void writer () { while (true) { semWait (y); writecount++; if (writecount == 1) semWait (rsem); semSignal (y); semWait (wsem); WRITEUNIT(); semSignal (wsem); semWait (y); writecount--; if (writecount == 0) semSignal (rsem); semSignal (y); } } void main() { readcount = writecount = 0; parbegin (reader, writer); }
Figure 5. 23 A Solution to the Readers/Writers Problem Using
Semaphores: Writers Have Priority Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 64 / 67
Mutual Exclusion and Synchronization Readers/Writers Problem
R/W in Message Passing (1/2)
Message Passing solution involves a control process that has access tothe shared data area
Readers and Writers send request messages to the controller to getaccess to the data area
controller grants access with �OK� message is receivedreader/writers indicate the completion with ��nished� message
Controller has mail boxes for each type msgthe controller serves write requests before read requests by emptyingthe write mailbox �rst
To guarantee mutual exclusion, variable count is usedinitialized to greater than the maximum number of readerscount > 0: no writer is waiting, service all ��nished� to clear activereaders, service write requests and then read requestscount = 0: only one outstanding write request, allow the write toproceed and wait for a ��nished� messagecount < 0: writer has made a request and is waiting for outstandingreaders, serve only ��nished� messages
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 65 / 67
Mutual Exclusion and Synchronization Readers/Writers Problem
R/W in Message Passing (2/2)
void reader(int i) { message rmsg; while (true) { rmsg = i; send (readrequest, rmsg); receive (mbox[i], rmsg); READUNIT (); rmsg = i; send (finished, rmsg); } } void writer(int j) { message rmsg; while(true) { rmsg = j; send (writerequest, rmsg); receive (mbox[j], rmsg); WRITEUNIT (); rmsg = j; send (finished, rmsg); } }
void controller() { while (true) { if (count > 0) { if (!empty (finished)) { receive (finished, msg); count++; } else if (!empty (writerequest)) { receive (writerequest, msg); writer_id = msg.id; count = count – 100; } else if (!empty (readrequest)) { receive (readrequest, msg); count--; send (msg.id, "OK"); } } if (count == 0) { send (writer_id, "OK"); receive (finished, msg); count = 100; } while (count < 0) { receive (finished, msg); count++; } } }
Figure 5.24 A Solution to the Readers/Writers Problem Using Message Passing
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 66 / 67
Mutual Exclusion and Synchronization Readers/Writers Problem
Shared vs. Share-Nothing Concurrency
In shared concurrency processes/threads see others memory
one process can write others memory and cause bugs that manifest alot later ⇒ hard to debug
allows very e�cient communication and synchronization
In share-nothing concurrency processes must communicate via messages
single entry/exit point for the data ⇒ easer to separate and verify thecorrectness of communication
synchronization is still an issue
you can have deadlocks, starvation and such
can be ine�cient when compared to shared memory
but you can have both: message passing on top of shared memory
Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 67 / 67