Chapter 5 Concurrency

based on: William Stallings Operating SystemsInternals and Design Principles, 6th ed. Pearson Education International Peter Sturm, UoTrier Operating Systems course

Chapter Table of Contents

Informatik CAU Kiel

1. Principles of Concurrency 2. Mutual Exclusion: Hardware Support 3. Semaphores 4. Monitors 5. Message Passing 6. Readers/Writers Problem

1. Principles of Concurrency

Principles of Concurrency
Informatik CAU Kiel

Three contexts to discuss concurrency

Multiprogramming, multiprocessing: sharing of resources Structured application design: application programs may be programmed as a set of concurrent processes/threads Operating system design: Operating Systems often themselves implemented as a set of concurrent processes/threads

Principles of Concurrency
Informatik CAU Kiel

You remember
time P1 P2 P3 Multiprogramming, one processor: interleaving P1 P2 P3 Multiprocessing, two processors: interleaving and overlapping blocked running

Principles of Concurrency
Informatik CAU Kiel

Stallings, p. 207: "At first glance, it may seem that interleaving and overlapping represent fundamentally different modes of execution and present different problems. In fact, [] both present the same problems."

Why?
Some of those problems
Sharing of global resources Optimal resource allocation Locating programming errors
7

Principles of Concurrency
Informatik CAU Kiel

A simple example
void echo() { chin = getchar(); chout = chin; putchar(chout); }

One character is read from the keyboard one keystroke at a time, stored in variable chin, and sent out to the screen for display.

Principles of Concurrency
Informatik CAU Kiel

A simple example (cont'd.)

Let's assume, two overlapping processes P1 and P2 use this simple routine.
Process P1 chin = getchar(); chout = chin; putchar(chout); Process P2 chin = getchar(); chout = chin; putchar(chout);

P1's input is lost; for both P1 and P2 the same character is sent to the screen!
9

Principles of Concurrency
Informatik CAU Kiel

A simple example (cont'd.)

Let's assume, two interleaving processes P1 and P2 use this simple routine.
Process P1 chin = getchar(); chout = chin; putchar(chout); Process P2 chin = getchar(); chout = chin; putchar(chout);

P1's input is lost; for both P1 and P2 the same character is sent to the screen!

10

Principles of Concurrency
Informatik CAU Kiel

How to avoid the flaw

Serialization
o

Execute the instances of the echo routine such that one instance runs after the other. No parallelism and no error, but also no gain in performance

Atomicity
o

Sequence of instructions that cant be interrupted

Serialization and atomicity combined = mutual exclusion

o o

Mutual exclusion required for so-called critical sections At most one thread inside critical section at any time
11

Principles of Concurrency
Informatik CAU Kiel

A simple example (resumed)

Let's assume, two parallel processes P1 and P2 enter their critical sections under mutual exclusion.
Process P1 enterCritical(); chin = getchar(); chout = chin; putchar(chout); exitCritical(); /* something else */ Process P2 enterCritical(); P2 is blocked! chin = getchar(); chout = chin; putchar(chout); exitCritical(); /* something else */

12

Principles of Concurrency
Informatik CAU Kiel

Key terms
atomic operation A sequence of one or more statements that appears to be indivisible; that is, no other process can see an intermediate state or interrupt the operation. critical section A section of code within a process that requires access to shared resources and that may not be executed while another process is in a corresponding section of code. A situation in which two or more processes are unable to proceed because each is waiting for one of the others to do something. A situation in which two or more processes continuously change their state in response to changes in the other process(es) without doing any useful work.

deadlock Iivelock

mutual exclusion The requirement that, when one process is in a critical section that accesses shared resources, no other process may be in a critical section that accesses any of those shared resources.

13

Principles of Concurrency
Informatik CAU Kiel

Key terms
race condition

(cont'd.) A situation in which multiple threads or processes read and write a shared data item and the final result depends on the relative timing of their execution. A situation in which a runnable process is overlooked indefinitely by the scheduler; although it is able to proceed, it is never chosen.

starvation

14

Principles of Concurrency
Informatik CAU Kiel

Degree of process interaction

Degree of Awareness Relationship Processes unaware of Competition each other for resources Influence that Processes Have on Each Other Results of one process independent of the action of others Potential Control Problems Mutual exclusion Deadlock (renewable resource) Starvation Mutual exclusion Deadlock (renewable resource) Starvation Data coherence Deadlock (consumable resource) Starvation
15

Processes indirectly aware of each other (e.g., shared object)

Cooperation by Results of one process sharing may depend on information obtained from others Cooperation by Results of one process communication may depend on information obtained from others

Processes directly aware of each other (use communication primitives)

Principles of Concurrency
Informatik CAU Kiel

Competition among Processes for Resources

Control problem 1: Mutual Exclusion
o

OS must provide means to protect critical sections, e.g. enterCritical, exitCritical functions

Control problem 2: Deadlock

o

Assume two processes P1, P2, both requesting two resources R1, R2: If P1 holds R1, and P2 holds R2 neither can proceed OS must detect and resolve deadlocks

Control problem 3: Starvation

o

Assume three processes P1, P2, P3, all three needing R1: If P1 and P2 use R1 in turn, P3 will suffer from starvation
16

2. Mutual Exclusion: Hardware Support

Mutual Exclusion: Hardware Support

Informatik CAU Kiel

Requirements for mutual exclusion

Only one process at a time is allowed in a critical section. A process that halts in its non-critical section must do so without interfering with other processes. It must not be possible for a process requiring access to a critical section to be delayed indefinitively: no deadlock or starvation. A process wishing to access a critical section must not be delayed, when there is no other process using it. No assumptions must made about relative process speeds or number of processes. A process remains inside its critical section for a finite time only.
18

Mutual Exclusion: Hardware Support

Informatik CAU Kiel

Monoprocessor System: Interrupt Disabling

A process runs until it invokes an operating system service or until it is interrupted:
o o o

Disabling interrupts guarantees mutual exclusion Processor is limited in its ability to interleave programs Will not work in multiprocessor architecture

19

Mutual Exclusion: Hardware Support

Informatik CAU Kiel

Atomic instruction 1: Compare&Swap

int compare_and_swap (int *word, int testval, int newval) { int oldval; oldval = *word; if (oldval == testval) *word = newval; return oldval; }

Sequence of compare and swap cannot be interrupted by other processes. Value at *word is readable for all processes having access to shared memory
20

Mutual Exclusion: Hardware Support

Informatik CAU Kiel

Compare&Swap: example
/* 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)); }

21

Mutual Exclusion: Hardware Support

Informatik CAU Kiel

Atomic instruction 2: Exchange

void exchange (int register, int memory) { int temp; temp = memory; memory = register; register = temp; }

Instruction exchanges the content of a processor register with that of a memory location Exchange instruction can be found in Intel's IA-32 and IA-64 architectures
22

Mutual Exclusion: Hardware Support

Informatik CAU Kiel

Exchange: example
keyi is local variable Following expression holds: bolt + keyi = n

/* program mutualexclusion */ const int 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)); }

23

Mutual Exclusion: Hardware Support

Informatik CAU Kiel

Advantages of atomic instructions

Applicable to any number of processes on either a single processor or multiple processors sharing main memory. It is simple and therefore easy to verify. It can be used to support multiple critical sections.

Disadvantages
Busy-waiting consumes processor time. Starvation is possible when a process leaves a critical section and more than one process is waiting. Deadlock is possible.
24

3. Semaphores

Semaphores
Informatik CAU Kiel

OS and programming language based constructs for concurrency control

Semaphore Binary Semaphore Mutex Condition Variable Monitor An integer value used for signaling among processes. Aka counting semaphore or general semaphore. A semaphore that takes on only the values 0 and 1. Similar to a binary semaphore. The process that locks the mutex must be the one to unlock it. A data type that is used to block a process until a particular condition is true. A programming language construct that encapsulates variables, access procedures and initialization code within an abstract data type. The monitor's variable may only be accessed via its access procedures and only one process may be actively accessing the monitor at anyone time.

26

Semaphores
Informatik CAU Kiel

OS and programming language based constructs for concurrency control (cont'd.)

Event Flags A memory word used as a synchronization mechanism. A thread can wait for either a single event or a combination of events by checking one or multiple bits in the corresponding flag. The thread is blocked until all of the required bits are set (AND) or until at least one of the bits is set (OR). A means for two processes to exchange information and that may be used for synchronization. Mutual exclusion mechanism in which a process executes in an infinite loop waiting for the value of a lock variable to indicate availability.

Mailboxes/Messages Spinlocks

27

Semaphores
Informatik CAU Kiel

Semaphores are special variables used for signaling: A process waiting for a signal is suspended until that signal is sent. Properties of semaphores
Semaphores have an integer counter value and a queue for blocked processes/threads. Counter may be initialized to a nonnegative number. Wait operation decrements the semaphore count. Signal operation increments semaphore count.
28

Semaphores
Informatik CAU Kiel

E.W. Dijkstra: "The structure of the 'THE'-multiprogramming system" (1968)

P = proberen V = verhogen
29

Edsger W. Dijkstra
(1930 2002)

Semaphores
Informatik CAU Kiel

Semaphore Primitives s
value queue PCB PCB PCB

semWait s.value--; if (s. value < 0) { tail(s.queue) := k; block(k); }

semSignal s. value++; if (s. value <= 0) { ready(head(s.queue)) delhead(s.queue) }

31

Semaphores
Informatik CAU Kiel

Mutual exclusion by semaphores

Semaphore s = 1;
Thread 0 Thread 1

semWait(s);

semWait();

Critical Section
semSignal(s);

Critical Section
semSignal();

32

Semaphores
Informatik CAU Kiel

Example: Semaphore initialized with 3

P1: W P2: W P1: S P1: W P3: W P4: W P5: W P1:S

P4

P4 P5

P5

time

Invariant
There are never more than init non-blocking semWait calls than finished semSignal calls: non-blocking #semWait calls #semSignal calls + init
33

Semaphores
Informatik CAU Kiel

Binary Semaphore Primitives

34

Semaphores
Informatik CAU Kiel

Mutual Exclusion Using Semaphores

/* program mutualexclusion */ const int n = /* number of processes */; semaphore s = 1; void P(int i) { while (true) { semWait(s); /* critical section */; semSignal(s); /* remainder */; } void main() { parbegin (P(1), P(2), ... ,P(n)); }
35

Semaphores
Informatik CAU Kiel

Example

36

Semaphores
Informatik CAU Kiel

Example (cont'd.)

37

Semaphores
Informatik CAU Kiel

Processes using a semaphore

38

Semaphores
Informatik CAU Kiel

Producer/Consumer Problem
One or more producers are generating data and placing these in a buffer A single consumer is taking items out of the buffer one at time Only one producer or consumer may access the buffer at any one time Producer cant add data into full buffer and consumer cant remove data from empty buffer

39

Semaphores
Informatik CAU Kiel

Solution outline
producer while (true) { /* produce item v */ b[in] = v; in++; } consumer while (true) { while (in <= out) /*do nothing */; w = b[out]; out++; /* consume item w */ }

40

Semaphores
Informatik CAU Kiel

Producer/Consumer with infinite buffer

41

Semaphores
Informatik CAU Kiel

Binary semaphore solution #1 for the producer/ consumer problem with infinite buffer: incorrect!

42

Producer 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 semWaitB(s) n++ if (n==1) (semSignaIB(delay)) semSignaIB(s) semWaitB(s) n++ if(n==1) (semSignaIB(delay)) semSignaIB(s)

Consumer

s 1 0 0 0 1

n 0 0 1 1 1 1 1 0 0 0 1 1 1 1 1 0 0 0 0 1 1

delay 0 0 0 1 1 0 0 0 0 0 0 1 1 1 1 1 1 0 0 0 0

semWaitB(delay) semWaitB(s) n-semSignaIB(s)

1 0 0 1 0 0 0 1

if (n==0) (semWaitB(delay)) semWaitB(s) n-semSignaIB(s) if (n==0) (semWaitB(delay)) semWaitB(s) n-semSignalB(s)

1 0 0 1 1 0 0 1

Semaphores
Informatik CAU Kiel

Binary semaphore solution #2 for the producer/ consumer problem with infinite buffer: : correct!

44

Semaphores
Informatik CAU Kiel

General semaphore solution for the producer/ consumer problem with infinite buffer

45

Semaphores
Informatik CAU Kiel

Solution with circular buffer

46

Semaphores
Informatik CAU Kiel

Solution outline for the producer/consumer problem with circular buffer

producer while (true) { /* produce item v */ while ((in + 1) % n == out) /* do nothing */; b[in] = v; in = (in + 1) % n } consumer while (true) { while (in == out) /* do nothing */; w = b[out]; out = (out + 1) % n; /* consume item w */ }

47

Semaphores
Informatik CAU Kiel

General semaphore solution for the producer/consumer problem with circular buffer

48

Semaphores
Informatik CAU Kiel

Common Faults Using Semaphores

Thread 1 Thread 2 Thread 1 Thread 2 Thread 1 Thread 2

s.Wait()

s.Wait()

s.Wait()

s.Wait()

x.Wait()

y.Wait()

s.Signal() s.Signal()

s.Signal() s.Signal()

y.Signal() x.Signal()

Missing semWait or semSignal

o o o

Critical section is no critical section anymore Deadlocks Inconsistent counter values in general semaphores

Opposite calls to nested semaphores

o

Deadlocks
49

3. Monitors

Monitors
Informatik CAU Kiel

Monitor encapsulates shared data together with the access functions

Abstract data type (similar to a class in OO languages) Process enters monitor by invoking one of its procedures. Only one process may be executing in the monitor at a time. Attributed to Per Brinch Hansen and C.A.R. Hoare.

Monitor M { Shared Data; Entry f1 (Parameter) : Result { Statements; } ... Entry fn (Parameter) : Result { Statements; } }

51

Per Brinch Hansen

(1938 2007)

C.A.R. Hoare
(*1934)

Monitors
Informatik CAU Kiel

Structure of a monitor

54

Monitors
Informatik CAU Kiel

Compilers apply semaphores correctly mutual exclusion guaranteed

Monitor M { Shared Data; Entry f1 (Parameter) : Result { Statements; } ... Entry fn (Parameter) : Result { Statements; } }

Monitor M { Shared Data; Semaphore MonSem(1); Entry f1 (Parameter) : Result { MonSem.Wait(); Statements; MonSem.Signal(); } ... Entry fn (Parameter) : Result { MonSem.Wait(); Statements; MonSem.Signal(); } 55 }

Monitors
Informatik CAU Kiel

But
What happens, if a process/thread is blocked inside a monitor? Nobody else to enter the monitor? Deadlock? It follows a three-part story on a monitor-based solution for the producer/consumer problem.

56

Monitors
Informatik CAU Kiel

Producer/ Consumer Part 1

Producer

Monitor Buffer { Element b[n]; Semaphore BufferNotFull(n); Semaphore BufferNotEmpty(0); int Free := Used := 0; Entry Produce (Element e) { BufferNotFull.Wait(); b[Free] := e; Free := (Free+1) mod n; BufferNotEmpty.Signal(); } Entry Consume () : Element { Element e; BufferNotEmpty.Wait(); e = b[Used]; Used := (used+1) mod n; BufferNotFull.Signal(); return e; } } Consumer

Blocking inside monitor???

57

Monitors
Informatik CAU Kiel

Monitor Buffer b; Element e; Bool done; Forever { Produce e; repeat done := b.Produce(e); Yield(); until done; }

Producer/Consumer Part 2:
Busy Waiting to avoid blocking inside monitor?
Entry Produce (Element e) : Bool { if (count = n) return False; else { b[Free] := e; Free := (Free+1) mod n; count++; return True; } } 58

Monitors
Informatik CAU Kiel

Part 3: We introduce Condition Variables

Waiting for an event (e.g., I/O completion) inside a monitor is realized by condition variables. A condition variable indicates an event and has no value. If a thread must wait for an event to occur, that thread waits on the corresponding condition variable. If another thread causes an event to occur, that thread signals the corresponding condition variable. Thus, a condition variable has a queue for those threads that are waiting the corresponding event to occur to wait on. The private data section of a monitor now can have a number of condition variables, each of which has a queue for threads to wait on.59

Monitors
Informatik CAU Kiel

Condition Variables (CV)

CV:
Queue (q) PCB PCB PCB

CV.Wait()
o o

Calling thread will be blocked But monitor is free again

CV.Signal()
o o o

Some other thread k blocked at CV will become ready k must compete for monitor entrance again Different variants of Signal()
60

Monitors
Informatik CAU Kiel

Comparing Wait operations

Semaphores Can be used anywhere in a program, but should not be used in a monitor semWait() does not always block the caller (i.e., when the semaphore counter is greater than zero). semSignal() either releases a blocked thread, if there is one, or increases the semaphore counter. If semSignal() releases a blocked thread, the caller and the released thread both continue. Condition Variables Can only be used in monitors cvWait() always blocks the caller.

cvSignal() either releases a blocked thread, if there is one, or the signal is lost as if it never happens. If cvSignal() releases a blocked thread, the caller yields the monitor or continues (see below). Only one of the caller or the released thread can continue, but not both. 61

Monitors
Informatik CAU Kiel EQ

General Architecture of a Monitor

Entry Queue (EQ) Thread trying to enter the monitor

CQ1

CQ2 Monitor Variables CQk

Condition Queues (CQ) For each condition variable a queue for all the waiting threads

SQ

Signalling Queue (SQ) Threads that are possibly blocked after issuing a signal

WQ Exit Blocked Thread Active Thread (only 1)

Signaled Queue (WQ) Threads awaiting monitor re-entrance after receiving a signal

62

Monitors
Informatik CAU Kiel

Solution for the producer/consumer problem with a monitor

Calls to monitor functions

63

Monitors
Informatik CAU Kiel EQ

Whos next?
Any new thread outside who wants to enter? (EQ) Some thread that has been waiting in a Condition Queue (CQi)?
SQ

CQ1

CQ2 Monitor Variables CQk

Thread may leave CQi when some other thread emits a signal.

SQ is a special case Some versions of signal block the signaling thread and favor the signaled thread again.

WQ Exit Blocked Thread Active Thread (only 1)

64

Monitors
Informatik CAU Kiel

Different Monitor Semantics

Assigning different priorities to queues EQ, SQ und WQ EQp = WQp < SQp EQp = SQp < WQp EQp < WQp < SQp EQp < SQp < WQp Wait and Notify ("Mesa") Signal and Wait Signal and Continue Signal and Urgent Wait

Priority means, if threads are waiting on all these queues, threads in queues with higher priority are favorized.
P.A. Buhr, M. Fortier, M.H. Coffin Monitor Classification ACM Computing Survey, Vol. 27, No. 1, pp. 63-107, 1995
65

Monitors
Informatik CAU Kiel

Wait and Notify ("Mesa")

By calling notify, a process/thread sends a "notification" to the process/thread at the head of the corresponding condition queue. The sending process/thread continues to execute after sending the "notification". The notified process/thread will be resumed "at some convenient future time" when the monitor is available.

66

Monitors
Informatik CAU Kiel

"Mesa" monitor for the bounded buffer

67

Monitors
Informatik CAU Kiel Consumer 1 Producer

Monitor
Consumer 2

Why is there a loop in "Mesa" monitors?

Calling Notify() means
o o

Buffer contains at least 1 element Buffer contains at least 1 free slot

Sample problem avoided by insertion of the while loop: Some Consumer C2 might enter the monitor, before a notified Consumer C1 gets chance to take element.
68

Monitors
Informatik CAU Kiel

"Signal and Wait" variant

Signalling thread is blocked, signaled thread is resumed. Loop is not required. Disadvantage: Most of the time, signaled thread enters monitor just to leave it.

69

Monitors
Informatik CAU Kiel

Signal and Wait (Hoare)

70

Monitors
Informatik CAU Kiel EQ

"Signal and Continue"

Thread inside monitor signals condition variable CQ2 Conceptually, active thread must enter SQ The priority settings favor SQ again Now active thread is leaving monitor SQ is empty, so WQ is next Now this thread is leaving too Since SQ and WQ are emtpy, a new thread may enter

CQ1

CQ2 Monitor Variables CQk

SQ

WQ Exit

Blocked Thread Active Thread (only 1)

71

Monitors
Informatik CAU Kiel

Implementation of "Signal and Continue"

Priorities: EQp < WQp < SQp Data structures
o o Wait (Condition c) { c.c += 1; if (w.c > 0) semSignal(w.s); else semSignal(MonSem); P(c.s); c.c -= 1; w.c += 1; P(w.s); w.c -= 1; }

Semaphore c.s per cond. var. c Counter c.c counts the number of threads blocked on c
Entry fk (...) { semWait(MonSem); ... if (w.c > 0) semSignal(w.s); else semSignal(MonSem); }

Signal (Condition c) { if (c.c > 0) semSignal(c.s); }

72

Monitors
Informatik CAU Kiel EQ

"Signal and Urgent Wait"

Active thread signals condition variable CQ2 Active thread must enter SQ The priority settings favor WQ, so thread in WQ becomes active When this thread leaves monitor, the signaling thread will enter again When this thread leaves the monitor, another thread from EQ may enter

CQ1

CQ2 Monitor Variables CQk

SQ

WQ Exit Blocked Thread Active Thread (only 1)

73

4. Message Passing

Message Passing
Informatik CAU Kiel

Interacting processes have two fundamental requirements

Synchronization: Enforce mutual exclusion Exchange information not discussed so far!

Message passing provides both via two operations

send (destination, message) receive (source, message)

Advantage: MP available for both networked and shared memory systems

75

Message Passing
Informatik CAU Kiel

Synchronization
Sender and receiver may or may not be blocking (waiting for message) Blocking send
o

Sender is blocked until message is received

Blocking receive
o

Receiver is blocked until message is received

Rendezvous
o

Both sender and receiver are blocked

76

Message Passing
Informatik CAU Kiel

Synchronization
Non-blocking send, blocking receive
o o

Sender continues after sending irrespective of receive Receiver is blocked until the requested message arrives

Non-blocking send, non-blocking receive

o

Neither party is required to wait

77

Message Passing
Informatik CAU Kiel

Direct addressing
Send includes a specific identifier of the destination process Receive could require that the receiver explicitely designate a sender, i.e. receiver knows ahead of time from which process a message is expected Receive could use source parameter to return to the calling process when the receive operation has been performed.

78

Addressing
Informatik CAU Kiel

Indirect addressing
Messages are sent to a shared data structure consisting of queues Queues are sometimes called mailboxes One process sends a message to the mailbox and the other process picks up the message from the mailbox

79

Indirect Process Communication

Informatik CAU Kiel

80

General Message Format

Informatik CAU Kiel

81

Mutual Exclusion Using Messages

Informatik CAU Kiel

Assume: blocking receive, non-blocking send

box initialized with single message with null content

82

Producer/Consumer Messages
Informatik CAU Kiel

83

5. Readers/Writers Problem

Readers/Writers Problem
Informatik CAU Kiel

Any number of readers may simultaneously read the file Only one writer at a time may write to the file If a writer is writing to the file, no reader may read it Note:
Readers don't write, writers don't read Producer not a writer, but a reader+writer Consumer is not a reader, but a reader+writer

85

Readers have Priority

Informatik CAU Kiel

Solution with semaphores

86

Writers have Priority

Informatik CAU Kiel

Solution with semaphores

87

Writers have Priority

Informatik CAU Kiel

Solution with semaphores (cont'd.)

88

Readers/Writers Problem
Informatik CAU Kiel

Solution with message passing

89

Readers/Writers Problem
Informatik CAU Kiel

Solution with message passing

(cont'd.)

90

Feedback for this Chapter

Informatik CAU Kiel

Well understood easy material Mostly understood material is ok Hardly understood difficult material

91