Concurrency Mutual Exclusion and Synchronization Chapter 6 1

Concurrency: Mutual Exclusion and Synchronization Chapter 6 1

Concurrent Execution Effects n n n 2 Concurrent processes (or threads) often need to share data (maintained either in shared memory or files) and resources If there is no controlled access to shared data, some processes may get an inconsistent view of this data The action performed by concurrent processes will then depend on the order in which their execution is interleaved

Concurrent Processes: Another Example n n n 3 Process P 1 and P 2 are running same procedure Shared variable “a” Processes can be preempted anytime If P 1 is first interrupted after user input and P 2 executes entirely Then the character echoed by P 1 will be the one read by P 2 !! static char a; void echo() { cin >> a; cout << a; }

Critical Section Problem n n When a process executes code that manipulates shared data (or resource), we say that the process is in its critical section (CS) (for that shared data) The execution of critical sections must be mutually exclusive u n 4 At any time, only one process is allowed to execute in its critical section (even with multiple CPUs) Each process must then request permission to enter its critical section (CS)

Process General Structure Repeat Entry section Critical section Exit section Remainder section Until false; 5 Examples: - a control system that manipulates a termostat - a process that controls the robot in an automated factory floor - a control process in a satellite

Critical Section Problem n To design a protocol that the processes can use to cooperate and safely access their critical section u What is a protocol? u Processes’ actions should not depend on the order in which their execution is interleaved u Typically a symmetric solution is desirable 6

Critical Section Framework n Each process executes at nonzero speed but no assumption on the relative speed of the n processes n n 7 In a multiprocessor environment, memory hardware prevents simultaneous access to the same memory location No assumptions about order of interleaved execution

CS Solution Requirements n Mutual Exclusion u At any time, at most one process can be in its CS n Progress u If no process is executing in its CS, while some processes wish to enter their CS, only processes that are not in their remainder section (RS) can participate in the decision of which will enter its CS next. F This 8 selection cannot be postponed indefinitely

CS Solution Requirements n Bounded Waiting u There is a bound on the number of times that other processes are allowed to enter their CS, After a process has made a request to enter its CS and before the request is granted F This is required to make sure that no process suffers starvation F Is this condition sufficient to guarantee that there will be no startvation? 9

Solutions Types n Software solutions u Algorithms whose correctness does not rely on any other assumptions, beside those stated in the framework n Hardware solutions u Special n machine instructions are provided Operation system solutions u Special functions and data structures are provided to the programmer 10

Semaphores n n OS supported, synchronization tools that do not require busy waiting A semaphore S is an integer variable that, apart from initialization, can only be accessed through two atomic and mutually exclusive operations: u wait(S) n A process that has to wait is put in a blocked queue u Queue 11 and signal(S); also P(S) and V(S) of processes waiting on semaphore S

Semaphore Structure type semaphore = record count: integer; queue: list of process end; var S: semaphore; n n 12 When a process must wait for a semaphore S, it is blocked and put on the semaphore’s queue The signal operation removes one process from the semaphore queue and adds it to the list of ready processes u FIFO, or other policies can be used to select next process

Semaphore Atomic Operations wait(S): S. count--; if (S. count<0) { block this process place this process in S. queue } signal(S): S. count++; if (S. count<=0) { remove a process P from S. queue place this process P on ready list } 13 S. count must be initialized to a nonnegative value, depending on application

Semaphores Properties n n n When S. count >=0, |S. count| represents the number of processes that can execute wait(S) without being blocked When S. count<0, |S. count| represents the number of processes waiting on S Atomicity and mutual exclusion is achieved u No two process can completely execute wait() and signal() operations on the same semaphore at the same time, even with multiple CPUs n 14 Hence, the blocks of code defining wait(S) and signal(S) are, in fact, critical sections

Semaphores Atomic Property n n 15 The critical sections defined by wait(S) and signal(S) are very short, around 10 instructions Solutions: u For uniprocessor, disable interrupts during these operations F This does not work on a multiprocessor machine. u For multiprocessors, use previous software or hardware schemes. F The amount of busy waiting should be small.

Semaphore-Based Solutions n n 16 Case of n processes Initialize S. count to 1 Then only 1 process is allowed into CS (mutual exclusion) To allow k processes into CS, initialize S. count to k Process Pi: repeat wait(S); CS signal(S); RS forever

Semaphore-Based Synchronization n n 17 We have 2 processes: P 1 and P 2 Statement S 1 in P 1 needs to be performed before statement S 2 in P 2 Define a semaphore “synch” Initialize synch to 0 n n Proper synchronization is achieved as follows: P 1: S 1; signal(synch); n P 2: wait(synch); S 2;

The Producer/Consumer Problem n n A common paradigm for cooperating processes A producer process produces information that is consumed by a consumer process u Ex 1: a print program produces characters that are consumed by a printer u Ex 2: an assembler produces object modules that are consumed by a loader n 18 We need a buffer to hold items that are produced and eventually consumed

P/C: Unbounded Buffer n n n 19 We assume first an unbounded buffer consisting of a linear array of elements in points to the next item to be produced out points to the next item to be consumed

P/C: Unbounded Buffer n n 20 We need a semaphore S to perform mutual exclusion on the buffer u Only 1 process at a time can access the buffer We need another semaphore N to synchronize producer and consumer on the number N (= in - out) of items in the buffer u An item can be consumed only after it has been created

P/C: Unbounded Buffer n n n 21 The producer is free to add an item into the buffer at any time u It performs wait(S) before appending and signal(S) afterwards to prevent customer access It also performs signal(N) after each append to increment N The consumer must first do wait(N) to see if there is an item to consume and use wait(S)/signal(S) to access the buffer

P/C: Unbounded Buffer Init: S. count: =1; N. count: =0; in: =out: =0; append(v): b[in]: =v; in++; take(): w: =b[out]; out++; return w; Producer: repeat produce v; wait(S); append(v); signal(S); signal(N); forever critical sections 22 Consumer: repeat wait(N); wait(S); w: =take(); signal(S); consume(w); forever

P/C: Unbounded Buffer n Observations u Putting signal(N) inside the CS of the producer (instead of outside) has no effect since the consumer must always wait for both semaphores before proceeding u The consumer must perform wait(N) before wait(S), otherwise deadlock occurs if consumer enter CS while the buffer is empty n 23 Using semaphores is a difficult art. . .

P/C: Finite Circular Buffer of Size k n n 24 Can consume only when the number N of consumable items is at least 1 (now: N!=in-out) Can produce only when number E of empty spaces is at least 1

P/C: Finite Circular Buffer of Size k n Similar to previous case: u. A semaphore S to have mutual exclusion on buffer access is needed u A semaphore N to synchronize producer and consumer on the number of consumable items is needed n In addition u. A semaphore E to synchronize producer and consumer on the number of empty spaces is needed 25

P/C: Finite Circular Buffer of Size k Initialization: S. count: =1; in: =0; N. count: =0; out: =0; E. count: =k; append(v): b[in]: =v; in: =(in+1) mod k; take(): w: =b[out]; out: =(out+1) mod k; return w; 26 Producer: repeat produce v; wait(E); wait(S); append(v); signal(S); signal(N); forever Consumer: repeat wait(N); wait(S); w: =take(); signal(S); signal(E); consume(w); forever critical sections

The Dining Philosophers: A Classical Synchronization Problem n n 27 It Illustrates the difficulty of allocating resources among process without deadlock and starvation Five philosophers who only eat and think Each needs to use 2 forks for eating Only five forks are available

Dining Philosophers Problem n n Each philosopher is a process One semaphore per fork: array[0. . 4] of semaphores u Initialization: fork[i]. count: =1 for i: =0. . 4 u n 28 Deadlock if each philosopher starts by picking his left fork! Process Pi: repeat think; wait(fork[i]); wait(fork[i+1 mod 5]); eat; signal(fork[i+1 mod 5]); signal(fork[i]); forever

Dining Philosophers Problem n n 29 A solution: admit only 4 philosophers at a time that tries to eat Then 1 philosopher can always eat when the other 3 are holding 1 fork Hence, we can use another semaphore T that would limit at 4 the numb. of philosophers “sitting at the table” Initialize: T. count: =4 Process Pi: repeat think; wait(T); wait(fork[i]); wait(fork[i+1 mod 5]); eat; signal(fork[i+1 mod 5]); signal(fork[i]); signal(T); forever

Binary Semaphores n n The semaphores we have studied are called counting, or integer, semaphores Binary semaphores u Similar to counting semaphores except that “count” is Boolean valued u Counting semaphores can be implemented by binary semaphores. . . u Generally, more difficult to use than counting semaphores (eg: they cannot be initialized to an integer k > 1) 30

Binary Semaphores wait. B(S): if (S. value = 1) { S. value : = 0; } else { block this process place this process in S. queue } signal. B(S): if (S. queue is empty) { S. value : = 1; } else { remove a process P from S. queue place this process P on ready list } 31

Spinlocks n n n 32 They are counting semaphores that use busy waiting (instead of blocking) Useful on multi processors when critical sections last for a short time A small amount of CPU time can be wasted, but no process switch wait(S): S--; while S<0 do{}; signal(S): S++;

Semaphores Critique n n Semaphores provide a powerful tool for enforcing mutual exclusion and coordinate processes The wait(S) and signal(S) operations can be scattered among several processes. u Hence, n n 33 difficult to understand their effects Usage must be correct in all the processes One incorrect or malicious process can cause the rest of the processes to fail

Software solutions n Case of 2 processes u Algorithm 1, 2 and 3. Which are correct? u Algorithm 3 is correct (Peterson’s algorithm) n General case of n processes u Bakery n algorithm Notation u We start with 2 processes: P 0 and P 1 u When describing process Pi, Pj always denotes the other process (i != j) 34

Algorithm 1 Process Pi: Repeat{ while(turn!=i){}; CS turn: =j; RS }forever 35

Algorithm 1 The shared variable turn is initialized (to 0 or 1) before executing any Pi Pi’s critical section is executed iff turn = i n n n 36 n n Pi is busy waiting if Pj is in CS: mutual exclusion is satisfied Progress requirement is not satisfied since it requires strict alternation of CSs Ex: P 0 has a large RS and P 1 has a small RS. If turn=0, P 0 enters its CS and then its long RS (turn=1). P 1 enters its CS and then its RS (turn=0) and tries again to enter its CS: request refused! P 1 has to wait that P 0 leaves its RS.

Algorithm 1 Limitations n Algorithm 1 does not retain enough information about the state of each process u It remembers only which process is allowed to enter its CS u It does not allow a processes to enter its CS even when the other process is in its RS F It 37 has to wait its turn

Algorithm 2 Keep a boolean var for each process: flag[0] and flag[1] n Pi signals that it is ready to enter it’s CS by: flag[i]: =true n Process Pi: Repeat{ flag[i]: =true; while(flag[j]){}; CS flag[i]: =false; RS }forever 38

Algorithm 2 n n Mutual Exclusion is satisfied but not the progress requirement If we have the sequence: u T 0: flag[0]: =true u T 1: flag[1]: =true u Both FA 39 process will wait forever to enter their CS deadlock situation

Algorithm 3 : Peterson’s Algorithm n Initialization: u flag[0]: =flag[1]: =false u turn: = n n n 40 0 or 1 Willingness to enter CS specified by flag[i]: =true If both processes attempt to enter their CS simultaneously, only one turn value will last Exit section: specifies that Pi is unwilling to enter CS

Peterson’s Algorithm Process Pi: repeat flag[i]: =true; turn: =j; do {} while (flag[j] and turn=j); CS flag[i]: = false; RS forever 41

Proof of Correctness n Mutual exclusion is preserved since: u P 0 and P 1 are both in CS only if flag[0] = flag[1] = true and only if turn = i for each Pi (impossible) n Progress and bounded waiting requirements are also satisfied: u Pi cannot enter CS only when the while() loop condition Is: flag[ j] = true and turn = j. u If Pj is not ready to enter CS then flag[ j] = false and Pi can enter its CS 42

Proof of Correctness u If Pj has set flag[ j]=true and is in its while(), then either turn=i or turn=j u If turn=i, then Pi enters CS. If turn=j then Pj enters CS but will then reset flag[ j]=false on exit: allowing Pi to enter CS u but if Pj has time to reset flag[ j]=true, it must also set turn=i u since Pi does not change value of turn while stuck in while(), Pi will enter CS after at most one CS entry by Pj (bounded waiting) 43

Process Failures? n If the ME, progress, and bounded waiting criteria are satisfied, then a valid solution provides robustness against failure of a process in its RS u Since failure in RS is just like having an infinitely long RS n However, no valid solution can provide robustness against process failure in its CS u. A process Pi that fails in its CS does not signal that fact to other processes: for them Pi is still in its CS 44

Bakery Algorithm: n-process Case n Before entering their CS, each Pi receives a number. u Holder of smallest number enter CS (like in bakeries, ice-cream stores. . . ) n When Pi and Pj receive same number: u if n n i= ai for i=0, . . k

The bakery algorithm (cont. ) n Shared data: u Choosing: array[0. . n-1] of boolean; F initialized u Number: array[0. . n-1] of integer; F initialized n to false to 0 Correctness relies on the following fact: u If Pi is in CS and Pk has already chosen its number[k]!= 0, then (number[i], i) < (number[k], k) 46

Bakery Algorithm 47 Process Pi: Repeat{ choosing[i]: =true; number[i]: =max(number[0]. . number[n-1])+1; choosing[i]: =false; for j: =0 to n-1 do { while (choosing[j]) {}; while (number[j]!=0 and (number[j], j)<(number[i], i)){}; } CS number[i]: =0; RS }forever

Software Solutions Drawbacks n Processes that are requesting to enter their critical sections are busy waiting u n 48 Wasteful of processor time If CSs are long, it would be more efficient to block processes that are waiting. . . Just like what semaphores do!

Hardware Solutions: Interrupt Disabling n n n 49 On a uniprocessor: mutual exclusion is preserved but efficiency of execution is degraded: while in CS, we cannot interleave execution with other processes that are in RS On a multiprocessor: mutual exclusion is not preserved How good a solution is this? Generally not an acceptable solution!! Process Pi: Repeat{ disable interrupts critical section enable interrupts remainder section }forever

CS Hardware-Based Solutions n Hardware designers have proposed machines instructions that perform 2 actions atomically (indivisibly) on the same memory location u reading n and writing The execution of such an instruction is mutually exclusive, even with multiple CPUs u They can provide the basis for mutual exclusion u Algorithms for satisfying the 3 requirements of the CS problem are still needed 50

Test-and-Set Instruction n A C++ description of the ATOMIC test-and-set: bool testset(int& i) { if (i==0) { i=1; return true; } else { return false; } } 51

ME using Test-and-Set Instruction n n 52 Shared variable b is initialized to 0 Only the first Pi who sets b enter CS Process Pi: Repeat{ repeat{} until test-and-set(b); CS b: =0; RS }forever

Test-and-Set Limitations n Mutual exclusion is preserved u But if Pi enter CS, other Pj’s are busy waiting F Busy n When Pi exits CS, the selection of the next Pj to enter CS is arbitrary u No n bounded waiting; starvation is possible Processors, such as Pentium, often provide an atomic xchg(a, b) instruction that swaps the content of a and b. Also called swap() u 53 waiting is undesirable (a Bad Thing) xchg(a, b) suffers the same drawbacks as testand-set

Using xchg for Mutual Exclusion n n 54 Shared variable b is initialized to 0 Each Pi has a local variable k The only Pi that can enter CS is the one who finds b=0 Pi excludes all other Pj’s from their CSs by setting b to 1 Process Pi: Repeat{ k: =1 repeat xchg(k, b) until k=0; CS b: =0; RS }forever

BACK TO OS HELP: Monitors n Monitors are high-level language constructs u They provide functionality that is equivalent to that of semaphores but are easier to control n Can be found in many concurrent programming languages F Concurrent n 55 Pascal, Modula-3, u. C++, Java. . . Can be implemented by semaphores. . .

BACK TO OS HELP: Monitors n A software module containing: u One or more procedures u An initialization sequence u Local data variables n Characteristics: u Local variables accessible only by monitor’s procedures u A process enters the monitor by invoking one of its procedures u Only one process can be in the monitor at any one time 56

Monitor n The monitor ensures mutual exclusion u No n need to program this constraint explicitly Shared data are protected by placing them in the monitor u The monitor locks the shared data on process entry n Process synchronization is achieved by the programmer by using condition variables u. A 57 process may have to wait for conditions to be true before executing in the monitor

Condition Variables n CVs are local to the monitor u Accessible n only within the monitor CVs can be accessed and changed only by two functions: u cwait(a): blocks execution of the calling process on condition (variable) a F the process can resume execution only if another process executes csignal(a) u csignal(a): resumes execution of some process blocked on condition (variable) a. F If 58 several such processes exist: choose any one F If no such process exists: do nothing

Monitor n n 59 Awaiting processes are either in the entrance queue or in a condition queue A process puts itself into condition queue cn by issuing cwait(cn) csignal(cn) brings into the monitor 1 process in condition cn queue Hence, csignal(cn) blocks the calling process and puts it in the urgent queue (unless csignal is the last operation of the monitor procedure)

Unbounded P/C Problem n Two types of processes: uproducers uconsumers n n n 60 Synchronization is now confined within the monitor append(. ) and take(. ) are procedures within the monitor: they are the only means by which P/C can access the buffer If these procedures are correct, synchronization will be correct for all participating processes Producer. I: repeat produce v; Append(v); forever Consumer. I: repeat Take(v); consume v; forever

Monitor: Bounded P/C Problem n Monitor needs to hold the buffer: u buffer: n array[0. . k-1] of items; Two condition variables are needed: u notfull: csignal(notfull) indicates that the buffer is not full u notempty: csignal(notempty) indicates that the buffer is not empty n Buffer pointers and counts are needed: u nextin: 61 points to next item to be appended u nextout: points to next item to be taken u count: holds the number of items in buffer

Monitor: Bounded P/C Problem Monitor boundedbuffer: array[0. . k-1] of items; nextin: =0, nextout: =0, count: =0: integer; notfull, notempty: condition; Append(v): if (count=k) cwait(notfull); buffer[nextin]: = v; nextin: = nextin+1 mod k; count++; csignal(notempty); Take(v): if (count=0) cwait(notempty); v: = buffer[nextout]; nextout: = nextout+1 mod k; count--; csignal(notfull); 62

Conclusion n n 63 Critical section problem Synchronization hardware Semaphores Classical synchronization problems Monitors