1. Modified from Silberschatz, Galvin and Gagne & Stallings Lecture 10 Chapter 6: Process Synchronization

2. 2 CS 446/646 Principles of Computer Operating Systems Chapter 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores Classic Problems of Synchronization Monitors Synchronization Examples Atomic Transactions

3. 3 CS 446/646 Principles of Computer Operating Systems Objectives To introduce the critical-section problem, whose solutions can be used to ensure the consistency of shared data To present both software and hardware solutions of the critical-section problem To introduce the concept of an atomic transaction describe mechanisms to ensure atomicity

4. 4 CS 446/646 Principles of Computer Operating Systems Background Concurrent access to shared data may result in data inconsistency concurrency is a fundamental part of O/S design concurrency includes  communication among processes/threads  sharing of, and competition for system resources  cooperative processing of shared data  synchronization of process/thread activities  organized CPU scheduling  solving deadlock and starvation problems Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes

5. 5 CS 446/646 Principles of Computer Operating Systems  Concurrency can be viewed at different levels: multiprogramming — interaction between multiple processes running on one CPU (pseudo-parallelism) multithreading — interaction between multiple threads running in one process multiprocessors — interaction between multiple CPUs running multiple processes/threads (real parallelism) multicomputers — interaction between multiple computers running distributed processes/threads  the principles of concurrency are basically the same in all of these categories Process Interaction & Concurrency Software view Hardware view

6. 6 CS 446/646 Principles of Computer Operating Systems o processes unaware of each other they must use shared resources independently, without interfering, and leave them intact for the others P1P1 P2P2 resource o processes indirectly aware of each other they work on common data and build some result together via the data P2P2 P1P1 data o processes directly aware of each other they cooperate by communicating, e.g., exchanging messages P2P2 P1P1 messages  Whether processes or threads: three basic interactions Process Interaction & Concurrency

7. 7 CS 446/646 Principles of Computer Operating Systems Multithreaded shopping diagram and possible outputs >./multi_shopping grabbing the salad... grabbing the milk... grabbing the apples... grabbing the butter... grabbing the cheese... > >./multi_shopping grabbing the milk... grabbing the butter... grabbing the salad... grabbing the cheese... grabbing the apples... > Molay, B. (2002) Understanding Unix/Linux Programming (1st Edition).  Insignificant race condition in the shopping scenario there is a “ race condition ” if the outcome depends on the order of the execution Race Condition

8. 8 CS 446/646 Principles of Computer Operating Systems CPU  Insignificant race condition in the shopping scenario the outcome depends on the CPU scheduling or “interleaving” of the threads (separately, each thread always does the same thing) >./multi_shopping grabbing the salad... grabbing the milk... grabbing the apples... grabbing the butter... grabbing the cheese... > A B salad apples milk buttercheese >./multi_shopping grabbing the milk... grabbing the butter... grabbing the salad... grabbing the cheese... grabbing the apples... > A salad apples B milk buttercheese Race Condition

9. 9 CS 446/646 Principles of Computer Operating Systems  Insignificant race condition in the shopping scenario the CPU switches from one process/thread to another, possibly on the basis of a preemptive clock mechanism >./multi_shopping grabbing the salad... grabbing the milk... grabbing the apples... grabbing the butter... grabbing the cheese... > A B salad apples milk buttercheese CPU thread A thread B salad milk apples buttercheese Thread view expanded in real execution time Race Condition

10. 10 CS 446/646 Principles of Computer Operating Systems char chin, chout; void echo() { do { chin = getchar(); chout = chin; putchar(chout); } while (...); } A char chin, chout; void echo() { do { chin = getchar(); chout = chin; putchar(chout); } while (...); } B >./echo Hello world! Single-threaded echo Multithreaded echo (lucky) >./echo Hello world! 1 2 3 4 5 6 lucky CPU scheduling  Significant race conditions in I/O & variable sharing Race Condition

11. 11 CS 446/646 Principles of Computer Operating Systems char chin, chout; void echo() { do { chin = getchar(); chout = chin; putchar(chout); } while (...); } A >./echo Hello world! Single-threaded echo char chin, chout; void echo() { do { chin = getchar(); chout = chin; putchar(chout); } while (...); } B  Significant race conditions in I/O & variable sharing 1 5 6 2 3 4 unlucky CPU scheduling  Multithreaded echo (unlucky) >./echo Hello world! ee.... Race Condition

12. 12 CS 446/646 Principles of Computer Operating Systems void echo() { char chin, chout; do { chin = getchar(); chout = chin; putchar(chout); } while (...); } B void echo() { char chin, chout; do { chin = getchar(); chout = chin; putchar(chout); } while (...); } A >./echo Hello world! Single-threaded echo  Significant race conditions in I/O & variable sharing 1 5 6 2 3 4 unlucky CPU scheduling  Multithreaded echo (unlucky) >./echo Hello world! eH.... changed to local variables Race Condition

13. 13 CS 446/646 Principles of Computer Operating Systems  Significant race conditions in I/O & variable sharing in this case, replacing the global variables with local variables did not solve the problem we actually had two race conditions here:  one race condition in the shared variables and the order of value assignment  another race condition in the shared output stream: which thread is going to write to output first this race persisted even after making the variables local to each thread  generally, problematic race conditions may occur whenever resources and/or data are shared  by processes unaware of each other or processes indirectly aware of each other Race Condition

14. 14 CS 446/646 Principles of Computer Operating Systems Producer / Consumer Problem Suppose that we wanted to provide a solution to the consumer-producer problem that fills all the buffers. We can do so by having an integer count that keeps track of the number of full buffers.  Initially, count is set to 0.  incremented by the producer after it produces a new buffer,  decremented by the consumer after it consumes a buffer. http://gaia.ecs.csus.edu/~zhangd/oscal/ProducerConsumer/Producer Consumer.html http://gaia.ecs.csus.edu/~zhangd/oscal/ProducerConsumer/Producer Consumer.html while (true) { /* Produce an item */ while (((in = (in + 1) % BUFFER SIZE) == out) ; /* do nothing -- no free buffers */ buffer[in] = item; in = (in + 1) % BUFFER SIZE; } while (true) { while (in == out) ; // do nothing -- nothing to consume // remove an item from the buffer item = buffer[out]; out = (out + 1) % BUFFER SIZE; return item; }

15. 15 CS 446/646 Principles of Computer Operating Systems Producer / Consumer while (true) { /* produce an item and put in nextProduced */ while (count == BUFFER_SIZE) ; // do nothing buffer [in] = nextProduced; in = (in + 1) % BUFFER_SIZE; count++; } while (true) { while (count == 0) ; // do nothing nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; count--; /* consume the item in nextConsumed }

16. 16 CS 446/646 Principles of Computer Operating Systems Race Condition count++ could be implemented as register1 = count register1 = register1 + 1 count = register1 count-- could be implemented as register2 = count register2 = register2 - 1 count = register2 Consider this execution interleaving with “count = 5” initially: S0: producer execute register1 = count {register1 = 5} S1: producer execute register1 = register1 + 1 {register1 = 6} S2: consumer execute register2 = count {register2 = 5} S3: consumer execute register2 = register2 - 1 {register2 = 4} S4: producer execute count = register1 {count = 6 } S5: consumer execute count = register2 {count = 4}

17. 17 CS 446/646 Principles of Computer Operating Systems  How to avoid race conditions? find a way to keep the instructions together this means actually... reverting from too much interleaving and going back to “indivisible/atomic” blocks of execution!! thread A thread B chin='H' chin='e' putchar('e') chout='e'putchar('e') (a) too much interleaving may create race conditions (b) keeping “indivisible” blocks of execution avoids race conditions thread A thread B chin='H' chin='e' putchar('H') chout='e'putchar('e') Race Condition

18. 18 CS 446/646 Principles of Computer Operating Systems  The “indivisible” execution blocks are critical regions a critical region is a section of code that may be executed by only one process or thread at a time B A common critical region B A A’s critical region B’s critical region although it is not necessarily the same region of memory or section of program in both processes  but physically different or not, what matters is that these regions cannot be interleaved or executed in parallel (pseudo or real) Critical Regions

19. 19 CS 446/646 Principles of Computer Operating Systems enter critical region? exit critical region enter critical region? exit critical region critical regions can be protected from concurrent access by padding them with entrance and exit gates o a thread must try to check in, then it must check out  We need mutual exclusion from critical regions void echo() { char chin, chout; do { chin = getchar(); chout = chin; putchar(chout); } while (...); } BA void echo() { char chin, chout; do { chin = getchar(); chout = chin; putchar(chout); } while (...); } Critical Regions

20. 20 CS 446/646 Principles of Computer Operating Systems Critical Section do { entry section critical section exit session remainder section } while (TRUE);

21. 21 CS 446/646 Principles of Computer Operating Systems 1. thread A reaches the gate to the critical region (CR) before B 2. thread A enters CR first, preventing B from entering (B is waiting or is blocked) 3. thread A exits CR; thread B can now enter 4. thread B enters CR  Desired effect: mutual exclusion from the critical region critical region B A B A B A B A HOW is this achieved?? Mutual Exclusion

22. 22 CS 446/646 Principles of Computer Operating Systems Solution to Critical-Section Problem 1.Mutual Exclusion o If process P i is executing in its critical section, o then no other processes can be executing in their critical sections 2.Progress o If no process is executing in its critical section and there exist some processes that wish to enter their critical section, o then the selection of the processes that will enter the critical section next cannot be postponed indefinitely 3.Bounded Waiting o A bound must exist on the number of times that other processes are allowed to enter their critical sections after a process has made a request to enter its critical section and before that request is granted Assume that each process executes at a nonzero speed No assumption concerning relative speed of the N processes

23. 23 CS 446/646 Principles of Computer Operating Systems Peterson’s Solution Two process solution Assume that the LOAD and STORE instructions are atomic; that is, cannot be interrupted. The two processes share two variables: int turn; Boolean flag[2] The variable turn indicates whose turn it is to enter the critical section. The flag array is used to indicate if a process is ready to enter the critical section. flag[i] = true implies that process P i is ready!

24. 24 CS 446/646 Principles of Computer Operating Systems Algorithm for Process P i do { flag[i] = TRUE; turn = j; while (flag[j] && turn == j); critical section flag[i] = FALSE; remainder section } while (TRUE);

25. 25 CS 446/646 Principles of Computer Operating Systems 1. A and B each have their own lock; an extra toggle is also masking either lock 2. A arrives first, sets its lock, pushes the mask to the other lock and may enter 3. then, B also sets its lock & pushes the mask, but must wait until A’s lock is reset 4. A exits the CR and resets its lock; B may now enter critical region B A B A B A B A Peterson’s Solution

26. 26 CS 446/646 Principles of Computer Operating Systems 1. A and B each have their own lock; an extra toggle is also masking either lock 2.1 A is interrupted between setting the lock & pushing the mask; B sets its lock 2.2 now, both A and B race to push the mask: whoever does it last will allow the other one inside CR  mutual exclusion holds!! (no bad race condition) critical region B A B A B A pushed last, allowing A B A pushed last, allowing B Peterson’s Solution

27. 27 CS 446/646 Principles of Computer Operating Systems Synchronization Hardware Uniprocessors – could disable interrupts Currently running code would execute without preemption what guarantees that the user process is going to ever exit the critical region? meanwhile, the CPU cannot interleave any other task  even unrelated to this race condition Generally too inefficient on multiprocessor systems Operating systems using this not broadly scalable Modern machines provide special atomic hardware instructions  Atomic = non-interruptable Either test memory word and set value Or swap contents of two memory words

28. 28 CS 446/646 Principles of Computer Operating Systems Solution to Critical-section Problem Using Locks do { acquire lock critical section release lock remainder section } while (TRUE);  Many systems provide hardware support for critical section code

29. 29 CS 446/646 Principles of Computer Operating Systems 1. thread A reaches CR and finds the lock at 0 and sets it in one shot, then enters 1.1’ even if B comes right behind A, it will find that the lock is already at 1 2. thread A exits CR, then resets lock to 0 3. thread B finds the lock at 0 and sets it to 1 in one shot, just before entering CR critical region B A B A B A B A Atomic lock

30. 30 CS 446/646 Principles of Computer Operating Systems TestAndSet Instruction Definition: boolean TestAndSet (boolean *target) { boolean rv = *target; *target = TRUE; return rv: }

31. 31 CS 446/646 Principles of Computer Operating Systems Solution using TestAndSet Shared boolean variable lock., initialized to false. Solution: do { while ( TestAndSet (&lock )) ; // do nothing // critical section lock = FALSE; // remainder section } while (TRUE);

32. 32 CS 446/646 Principles of Computer Operating Systems Swap Instruction Definition: void Swap (boolean *a, boolean *b) { boolean temp = *a; *a = *b; *b = temp: }

33. 33 CS 446/646 Principles of Computer Operating Systems Solution using Swap Shared Boolean variable lock initialized to FALSE; Each process has a local Boolean variable key Solution: do { key = TRUE; while ( key == TRUE) Swap (&lock, &key ); // critical section lock = FALSE; // remainder section } while (TRUE);

34. 34 CS 446/646 Principles of Computer Operating Systems Bounded-waiting Mutual Exclusion with TestandSet() do { waiting[i] = TRUE; key = TRUE; while (waiting[i] && key) key = TestAndSet(&lock); waiting[i] = FALSE; // critical section j = (i + 1) % n; while ((j != i) && !waiting[j]) j = (j + 1) % n; if (j == i) lock = FALSE; else waiting[j] = FALSE; // remainder section } while (TRUE);

35. 35 CS 446/646 Principles of Computer Operating Systems Semaphore Synchronization tool that does not require busy waiting Semaphore S – integer variable Two standard operations modify S: wait() and signal() Less complicated Can only be accessed via two indivisible (atomic) operations wait (S) { while S <= 0 ; // no-op S--; } signal (S) { S++; }

36. 36 CS 446/646 Principles of Computer Operating Systems Semaphore as General Synchronization Tool Counting semaphore integer value can range over an unrestricted domain Binary semaphore integer value can range only between 0 and 1; can be simpler to implement Also known as mutex locks Can implement a counting semaphore S as a binary semaphore Provides mutual exclusion Semaphore mutex; // initialized to 1 do { wait (mutex); // Critical Section signal (mutex); // remainder section } while (TRUE);

37. 37 CS 446/646 Principles of Computer Operating Systems value = 1 (“off”) no queue signal value = 0 1 in queue wait value = 0 2 in queue wait... value = 0 3 in queue wait value = 0 (“on”) no queue wait Binary Semaphore

38. 38 CS 446/646 Principles of Computer Operating Systems value = +2 no queue value = –1 1 in queue wait 0... value = –2 2 in queue wait 00 value = 0 no queue wait 0 value = +1 no queue wait 0 signal Counting Semaphore

39. 39 CS 446/646 Principles of Computer Operating Systems Semaphore Implementation Must guarantee that no two processes can execute wait () and signal () on the same semaphore at the same time Thus, implementation becomes the critical section problem where the wait and signal code are placed in the critical section. Could now have busy waiting in critical section implementation  But implementation code is short  Little busy waiting if critical section rarely occupied Note that applications may spend lots of time in critical sections and therefore this is not a good solution.

40. 40 CS 446/646 Principles of Computer Operating Systems in busy waiting, the PC is always looping (increment & jump back) it can be preemptively interrupted but will loop again tightly whenever rescheduled  tight polling Blocke d Ready dispatch event wait (block) event occurs (unblock) timeout Running when blocked, the process’s PC stalls after executing a “yield” call either the process is only timed out, thus it is “Ready” to loop-and-yield again  sparse polling or it is truly “Blocked” and put in event queue  condition waiting Running dispatch voluntary event wait (block) event occurs (unblock) voluntary timeout Blocked Ready Busy waiting

41. 41 CS 446/646 Principles of Computer Operating Systems Semaphore Implementation with no Busy waiting With each semaphore there is an associated waiting queue. Each entry in a waiting queue has two data items:  value (of type integer)  pointer to next record in the list Two operations: Block  place the process invoking the operation on the appropriate waiting queue. wakeup  remove one of processes in the waiting queue and place it in the ready queue.

42. 42 CS 446/646 Principles of Computer Operating Systems Semaphore Implementation with no Busy waiting Implementation of wait: wait(semaphore *S) { S->value--; if (S->value < 0) { add this process to S->list; block(); } } Implementation of signal: signal(semaphore *S) { S->value++; if (S->value <= 0) { remove a process P from S->list; wakeup(P); } }

43. 43 CS 446/646 Principles of Computer Operating Systems Deadlock and Starvation Deadlock – two or more processes are waiting indefinitely for an event that can be caused by only one of the waiting processes Let S and Q be two semaphores initialized to 1 P 0 P 1 wait (S); wait (Q); wait (Q); wait (S);. signal (S); signal (Q); signal (Q); signal (S); Starvation – indefinite blocking. A process may never be removed from the semaphore queue in which it is suspended Priority Inversion - Scheduling problem when lower-priority process holds a lock needed by higher-priority process