1. OSes: 5. Synch 1 Operating Systems v Objectives –describe the synchronization problem and some common mechanisms for solving it Certificate Program in Software Development CSE-TC and CSIM, AIT September -- November, 2003 5. Process Synchronization (Ch. 6, S&G) ch 7 in the 6th ed.

2. OSes: 5. Synch 2 Contents 1.Motivation: Bounded Buffer 2.Critical Sections 3.Synchronization Hardware 4.Semaphores 5.Synchronization Examples continued

3. OSes: 5. Synch 3 6.Problems with Semaphores 7.Critical Regions 8.Monitors 9.Synchronization in Solaris 2 10.Atomic Transactions

4. OSes: 5. Synch 4 1. Motivation: Bounded Buffer 0123n-1 ….. producerconsumer writeread bounded buffer

5. OSes: 5. Synch 5 Producer Code (pseudo-Pascal) : repeat... /* produce an itemP */... while (counter == n) do no-op; buffer[in] := itemP; /* write */ in := (in+1) mod n; counter := counter + 1; until false; :

6. OSes: 5. Synch 6 Consumer Code : repeat while (counter == 0) do no-op; itemC := buffer[out]; /* read */ out := (out+1) mod n; counter := counter - 1;... /* use itemC for something */... until false; :

7. OSes: 5. Synch 7 Problem  Assume  Assume counter == 5  producer runconsumer run  producer runconsumer run :: counter := counter := counter + 1; counter - 1; ::  counter may now be 4, 5, or 6. Why?

8. OSes: 5. Synch 8 Machine Language  “counter := counter + 1” becomes: reg1 := counter reg1 := reg1 + 1 counter := reg1  “counter := counter - 1” becomes: reg2 := counter reg2 := reg2 - 1 counter := reg2

9. OSes: 5. Synch 9 Execution Interleaving v The concurrent execution of the two processes is achieved by interleaving the execution of each  There are many possible interleavings, which can lead to different values for counter –a different interleaving may occur each time the processes are run

10. OSes: 5. Synch 10 Interleaving Example  Initially: counter == 5 v Execution: reg1 := counter// reg1 == 5 reg1 := reg1 + 1// reg1 == 6 reg2 := counter// reg2 == 5 reg2 := reg2 - 1// reg2 == 4 counter := reg1// counter == 6 counter := reg2// counter == 4

11. OSes: 5. Synch 11 Summary of Problem  Incorrect results occur because of a race condition over the modification of the shared variable ( counter ) v The processes must be synchronized while they are sharing data so that the result is predictable and correct

12. OSes: 5. Synch 12 2. Critical Sections v A critical section is a segment of code which can only be executed by one process at a time –all other processes are excluded –called mutual exclusion

13. OSes: 5. Synch 13 Critical Section Pseudo-code repeat entry section critical section exit section remainder section until false;

14. OSes: 5. Synch 14 Implementation Features v An implementation of the critical section idea must have three features: –mutual exclusion –progress u the next process to enter the critical region is decided solely by looking at those waiting in their entry sections –bounded waiting u no process should wait forever in their entry section

15. OSes: 5. Synch 15 2.1. Solutions for Two Processes v Algorithm 1 (take turns) –shared data: –shared data: var turn: 0..1 := 0; /* or 1 */ –Code for process i: –Code for process i: repeat while (turn /== i) do no-op: critical section; turn := j; remainder section; until false; progress requirement not met

16. OSes: 5. Synch 16 Algorithm2 (who wants to enter?) v Shared data: var flag : array [0..1] of boolean := {false, false}; v Code for process i: repeat flag[i] := true; while (flag[j]) do no-op: critical section; flag[i] := false; remainder section; until false; progress requirement still not met

17. OSes: 5. Synch 17 Algorithm 3 (Peterson, 1981) v Combines algorithms 1 and 2 –who wants to enter? –if both do then take turns v Shared data: var flag : array [0..1] of boolean := {false, false}; var turn : 0..1 := 0; /* or 1 */ continued

18. OSes: 5. Synch 18 v Code for process i: repeat flag[i] := true; turn := j; while (flag[j] and turn == j) do no-op: critical section; flag[i] := false; remainder section; until false;

19. OSes: 5. Synch 19 2.2. Multiple Processes v Uses the bakery algorithm (Lamport 1974). v Each customer (process) receives a number on entering the store (the entry section). v The customer with the lowest number is served first (enters the critical region). continued

20. OSes: 5. Synch 20 v If two customers have the same number, then the one with the lowest name is served first –names are unique and ordered

21. OSes: 5. Synch 21 Pseudo-code v Shared data: var choosing : array [0..n-1] of boolean := {false.. false}; var number : array [0..n-1] of integer := {0.. 0}; continued

22. OSes: 5. Synch 22 v Code for process i: repeat choosing[i] := true; number[i] := max(number[0], number[1],..., number[n-1]) + 1; choosing[i] := false; for j := 0 to n-1 do begin while (choosing[j]) do no-op; while ((number[j] /== 0) and ((number[j],j) < (number[i],i))) do no-op; end; critical section number[i] := 0; remainder section until false;

23. OSes: 5. Synch 23 3. Synchronization Hardware v Hardware solutions can make software synchronization much simpler v On a uniprocessor, the OS can disallow interrupts while a shared variable is being changed –not so easy on multiprocessors continued

24. OSes: 5. Synch 24 v Typical hardware support: –atomic test-and-set of a boolean (byte) –atomic swap of booleans (bytes) v Atomic means an uninterruptable ‘unit’ of work.

25. OSes: 5. Synch 25 3.1. Atomic Test-and-Set function Test-and-Set( var target : boolean) : boolean begin Test-and-Set := target; target := true; end;

26. OSes: 5. Synch 26 Use v Shared data: var lock : boolean := false; v Process code for mutual exclusion: repeat while (Test-and-Set(lock) do no-op; critical section lock := false; remainder section until false; lock/inlock/outresultaction F T Fproceed T T Tloop

27. OSes: 5. Synch 27 3.2. Atomic Swap procedure Swap(var a, b : boolean) var temp : boolean; begin temp := a; a := b; b := temp; end;

28. OSes: 5. Synch 28 Use v Shared data: var lock : boolean := false; v Process code for m.e.: var key : boolean: repeat key := true; repeat Swap(lock, key); until (key == false); critical section lock := false; remainder section until false; key1key2…keyNlock in: T T… T F

29. OSes: 5. Synch 29 3.3. Bounded Waiting v TestAndSet() and Swap() both satisfy the requirements of mutual exclusion and progress v But bounded waiting is not satisfied v We must add an extra data structure to code FIFO (queueing-style) behaviour

30. OSes: 5. Synch 30 4. Semaphores (Dijkstra, 1965) v Semaphores are a synchronization tool based around two atomic operations: –wait() sometimes called P() –signal() sometimes called V()

31. OSes: 5. Synch 31 4.1. Definitions procedure wait(var S : semaphore) begin while (S =< 0) do no-op; S := S - 1; end; procedure signal(var S : semaphore) begin S := S + 1; end; same as integer

32. OSes: 5. Synch 32 4.2. Mutual Exclusion with Semaphores v Shared data: var mutex : semaphore := 1; v Process code: repeat wait(mutex); critical section; signal(mutex); remainder section; until false;

33. OSes: 5. Synch 33 4.3. Ordering Processes  Establish a fixed order for two processes p 1 and p 2, We set semaphore Order := 0.  If the desired order is p 1 -> p 2, p 2 should issue a wait(Order), and then wait until p 1 issues a signal(Order).

34. OSes: 5. Synch 34 4.4. Counting Semaphores  Allow N processes into a critical section, by initialising semaphore Limit to N –the first N processes each decrement Limit using wait(Limit), until Limit == 0, at which time new processes must wait v This approach is used for controlling access to a limited number of resources (e.g. N resources)

35. OSes: 5. Synch 35 4.5. Implementations  Our wait() implementation uses busy-waiting –sometimes called a spinlock  An alternative is for the process calling wait() to block –place itself on a wait list associated with the semaphore –signal() chooses a blocked process to become ready

36. OSes: 5. Synch 36 New Semaphore Data Type type semaphore = record value : integer; L : list of waiting-processes; end;

37. OSes: 5. Synch 37 New Operations procedure wait(var S : semaphore) begin S.value := S.value - 1; if (S.value < 0) then begin /* add the calling process to S.L */... block; end; end; continued

38. OSes: 5. Synch 38 procedure signal(var S : semaphore) begin S.value := S.value + 1; if (S.value =< 0) then begin /* remove a process P from S.L */... wakeup(P); end; end;

39. OSes: 5. Synch 39 4.6. Deadlocks & Starvation  Deadlock occurs when every process is waiting for a signal(S) call that can only be carried out by one of the waiting processes. v Starvation occurs when a waiting process never gets selected to move into the critical region.

40. OSes: 5. Synch 40 4.7. Binary Semaphores v A binary semaphore is a specialisation of the counting semaphore with S only having a range of 0..1 –S starts at 0 –easy to implement –can be used to code up counting semaphores

41. OSes: 5. Synch 41 5. Synchronization Examples v 5.1. Bounded Buffer v 5.2. Readers and Writers v 5.3. Dining Philosophers

42. OSes: 5. Synch 42 5.1. Bounded Buffer (Again) 0123n-1 ….. producerconsumer writeread bounded buffer

43. OSes: 5. Synch 43 Implementation v Shared data: var buffer : array[0..n-1] of Item; var mutex : semaphore := 1; /* for access to buffer */ var full : semaphore := 0; /* num. of used array cells */ var empty : semaphore := n; /* num. of empty array cells */

44. OSes: 5. Synch 44 Producer Code repeat... /* produce an itemP */... wait(empty); wait(mutex); buffer[in] := itemP; in := (in+1) mod n; signal(mutex); signal(full); until false;

45. OSes: 5. Synch 45 Consumer Code repeat wait(full); wait(mutex); itemC := buffer[out]; out := (out+1) mod n; signal(mutex); signal(empty);... /* use itemC for something */... until false;

46. OSes: 5. Synch 46 5.2. Readers & Writers v Readers make no change to the shared data (e.g. a file) –no synchronization problem v Writers do change the shared data v Multiple writers (or a writer and readers) cause a synchronization problem.

47. OSes: 5. Synch 47 Many Variations v 1. Don’t keep a reader waiting unless a writer is already using the shared data –writers may starve v 2. Don’t keep a writer waiting –readers may starve

48. OSes: 5. Synch 48 Variation 1 v Shared data: var shared-data : Item; var readcount : integer : = 0; /* no. of readers currently using shared-data */ var mutex : semaphore := 1; /* control access to readcount */ var wrt : semaphore := 1; /* used for m.e. of writers */

49. OSes: 5. Synch 49 Writer’s Code : wait(wrt);... /* writing is performed */... signal(wrt); :

50. OSes: 5. Synch 50 Reader’s Code wait(mutex); readcount := readcount + 1; if (readcount == 1) then wait(wrt); signal(mutex);... /* reading is performed */... wait(mutex); readcount := readcount - 1; if (readcount == 0) then signal(wrt); signal(mutex);

51. OSes: 5. Synch 51 5.3. Dining Philosophers v An example of the need to allocate several resources (chopsticks) among processes (philosophers) in a deadlock and starvation free manner. Dijkstra, 1965

52. OSes: 5. Synch 52 Implementation v Represent each chopstick by a semaphore. Shared data: var chopstick : array[0..4] of semaphore := {1,1,1,1,1};  A chopstick is ‘picked up’ with: wait(chopstick[pos]) and ‘set down’ with: signal(chopstick[pos])

53. OSes: 5. Synch 53 Code for Philopospher i repeat wait( chopstick[i] ); wait( chopstick[(i+1) mod 5] ); /*... eat... */ signal( chopstick[i] ); signal( chopstick[(i+1) mod 5] ); /*... think... */ until false;

54. OSes: 5. Synch 54 Deadlock v This solution avoids simultaneous use of chopsticks (good) v But if all the philosophers pick up their left chopstick together, then they will deadlock while waiting for access to their right chopstick.

55. OSes: 5. Synch 55 Possible Fixes v Allow at most 4 philosophers to be at the table at a time. v Have a philosopher pick up their chopsticks only if both are available (in a critical section) v Alternate the order that chopsticks are picked up depending on whether the philosopher is seated at an odd or even seat

56. OSes: 5. Synch 56 6. Problems with Semaphores  The reversal of a wait() and signal() pair will break mutual exclusion  The omission of either a wait() or signal() will potentially cause deadlock v These problems are difficult to debug and reproduce

57. OSes: 5. Synch 57 Higher level Synchronization v These problems have motivated the introduction of higher level constructs: –critical regions –monitors –condition variables v These constructs are safer, and easy to understand

58. OSes: 5. Synch 58 7. Critical Regions v Shared variables are explicitly declared: var v : shared ItemType;  A shared variable can only be accessed within the code part ( S ) of a region statement: region v do S –while code S is being executed, no other process can access v Hoare, 1972; Brinch Hansen, 1972

59. OSes: 5. Synch 59 Conditional Critical Regions  region v when B do S –only execute S when the boolean expression B evaluates to true, otherwise wait until B is true –as before, while code S is being executed, no other process can access v

60. OSes: 5. Synch 60 Bounded Buffer Again v Shared data: var buffer : shared record pool : array[0..n-1] of Item; count, in, out : integer; end;

61. OSes: 5. Synch 61 Producer Code region buffer when (count < n) do begin pool[in] := itemP; in := (in+1) mod n; count := count + 1; end;

62. OSes: 5. Synch 62 Consumer Code region buffer when (count > 0) do begin itemC := pool[out]; out := (out+1) mod n; count := count - 1; end;

63. OSes: 5. Synch 63 8. Monitors Brinch Hansen, 1973 shared data initialization code operations var queues associated with condition variables entry queue of waiting processes Fig. 6.20, p.184

64. OSes: 5. Synch 64 Monitor Syntax type monitor-name = monitor variable declarations procedure entry p1(...) begin... end; : begin initialization code end.

65. OSes: 5. Synch 65 Features v When an instance of a monitor is created, its initialization code is executed v A procedure can access its own variables and those in the monitor’s variable declarations v A monitor only allows one process to use its operations at a time

66. OSes: 5. Synch 66 An OO View of Monitors v A monitor is similar to a class v An instance of a monitor is similar to an object, with all private data v Plus synchronization: invoking any operation (method) results in mutual exclusion over the entire object

67. OSes: 5. Synch 67 8.1. Condition Variables v Notation: var x : condition; x.wait; u suspend calling process x.signal;  resumes one of the suspended processes waiting on x

68. OSes: 5. Synch 68 Condition Variables in Monitors  What happens when signal is issued?  The unblocked process will be placed on the ready queue and resume from the statement following the wait. v This would violate mutual exclusion if both the signaller and signalled process are executing in the monitor at once.

69. OSes: 5. Synch 69 Three Possible Solutions  1. Have the signaller leave the monitor immediately after calling signal v 2. Have the signalled process wait until the signaller has left the monitor v 3. Have the signaller wait until the signalled process has left the monitor

70. OSes: 5. Synch 70 8.2. Dining Philosophers (Again)  Useful data structures:  Useful data structures: var state : array[0..4] of (thinking, hungry, eating); var self : array[0..4] of condition; /* used to delay philosophers */  The approach is to only set state[i] to eating if its two neigbours are not eating –i.e. state[(i+4) mod 5] = eating and state[(i+1) mod 5] = eating

71. OSes: 5. Synch 71 Using the dining-philosophers Monitor v Shared data: var dp : dining-philosopher; v Code in philosopher i: dp.pickup(i): /*... eat... */ dp.putdown(i);

72. OSes: 5. Synch 72 Monitor implementation type dining-philosophers = monitor var state : array[0..4] of (thinking, hungry, eating); var self : array[0..4] of condition; procedure entry pickup(i : 0..4) begin state[i] := hungry; test(i); if (state[i] /== eating) then self[i].wait; end; continued

73. OSes: 5. Synch 73 procedure entry putdown(i : 0..4) begin state[i] := thinking; test((i+4) mod 5); test((i+1) mod 5); end; continued

74. OSes: 5. Synch 74 procedure test(k : 0..4) begin if ((state[(k+4) mod 5] /== eating) and (state[k] == hungry) and (state[(k+1) mod 5] /== eating)) then begin state[k] := eating; self[k].signal; end; end; continued

75. OSes: 5. Synch 75 begin /* initialization of monitor instance */ for i := 0 to 4 do state[i] := thinking; end.

76. OSes: 5. Synch 76 8.3. Problems with Monitors v Even high level operations can be misused. v For correctness, we must check: –that all user processes always call the monitor operations in the right order; –that no user process bypasses the monitor and uses a shared resource directly –called the access-control problem

77. OSes: 5. Synch 77 9. Synchronization in Solaris 2 v Uses a mix of techniques: –semaphores using spinlocks –thread blocking –condition variables (without monitors) –specialised reader-writer locks on data

78. OSes: 5. Synch 78 10. Atomic Transactions v We want to do all the operations of a critical section as a single logical ‘unit’ of work –it is either done completely or not at all  A transaction can be viewed as a sequence of read s and write s on shared data, ending with a commit or abort operation  An abort causes a partial transaction to be rolled back

79. OSes: 5. Synch 79 10.1. Log-based Recovery v Atomicity is ensured by logging transaction operations to stable storage –these can be replayed or used for rollback if failure occurs v Log details: –transaction name, data name, old value, new value continued

80. OSes: 5. Synch 80 v Write-ahead logging: –log a write operation before doing it –log the transaction start and its commit

81. OSes: 5. Synch 81 Example begin transaction read X if (X >= a) then { read Y X = X - a Y = Y + a write X write Y } end transaction (VUW CS 305)

82. OSes: 5. Synch 82 Recovery v Operations: –undo( Transaction i ) –redo( Transaction i )  Possible states of Transaction i –committed, but were new values written? –aborted, but were old values restored? –unfinished

83. OSes: 5. Synch 83 10.2. Checkpoints v A checkpoint fixes state changes by writing them to stable storage so that the log file can be reset or shortened.

84. OSes: 5. Synch 84 10.3. Concurrent Atomic Transactions v We want to ensure that the outcome of concurrent transactions are the same as if they were executed in some serial order –serializability

85. OSes: 5. Synch 85 A Serial Schedule  Transaction 0Transaction 1 read A write A read B write B read A write A read B write B Fig. 6.23, p.195

86. OSes: 5. Synch 86 Conflicting Operations  Two operations in different transactions conflict if they access the same data and one of them is a write. v Serializability must avoid conflicting operations: –it can do that by delaying/speeding up when operations in a transaction are performed

87. OSes: 5. Synch 87 A Concurrent Serializable Schedule  Transaction 0Transaction 1 read A write A read A write A read B write B read B write B Fig. 6.24, p.196

88. OSes: 5. Synch 88 10.4. Locks v Serializability can be achieved by locking data items v There are a range of locking modes: –a shared lock allows multiple reads by different transactions –an exclusive lock allows only one transaction to do reads/writes

89. OSes: 5. Synch 89 10.5. Timestamping v One way of ordering transactions v Using the system clock is not sufficient when transactions may originate on different machines