Operating Systems

1. Operating Systems Certificate Program in Software DevelopmentCSE-TC and CSIM, AITSeptember -- November, 2003 • Objectives • describe the synchronization problem and some common mechanisms for solving it 5. Process Synchronization(Ch. 6, S&G) ch 7 in the 6th ed.

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

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

4. 1. Motivation: Bounded Buffer bounded buffer ….. ….. 0 1 2 3 n-1 producer consumer write read

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. 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. Problem • Assume counter == 5 • producer run consumer run : :counter := counter := counter + 1; counter - 1; : : • counter may now be 4, 5, or 6. Why?

8. Machine Language • “counter := counter + 1” becomes: reg1 := counterreg1 := reg1 + 1counter := reg1 • “counter := counter - 1” becomes: reg2 := counterreg2 := reg2 - 1counter := reg2

9. Execution Interleaving • 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. Interleaving Example • Initially: counter == 5 • Execution: reg1 := counter // reg1 == 5reg1 := reg1 + 1 // reg1 == 6reg2 := counter // reg2 == 5reg2 := reg2 - 1 // reg2 == 4counter := reg1 // counter == 6counter := reg2 // counter == 4

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

12. 2. Critical Sections • 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. Critical Section Pseudo-code repeat entry section critical section exit section remainder sectionuntil false;

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

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

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

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

18. 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. 2.2. Multiple Processes • Uses the bakery algorithm (Lamport 1974). • Each customer (process) receives a number on entering the store (the entry section). • The customer with the lowest number is served first (enters the critical region). continued

20. If two customers have the same number, then the one with the lowest name is served first • names are unique and ordered

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

22. 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 sectionuntil false;

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

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

25. 3.1. Atomic Test-and-Set function Test-and-Set( var target : boolean) : booleanbegin Test-and-Set := target; target := true;end;

26. lock/in lock/out result action F T F proceed T T T loop Use • Shared data: var lock : boolean := false; • Process code for mutual exclusion: repeat while (Test-and-Set(lock) do no-op; critical section lock := false; remainder sectionuntil false;

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

28. key1 key2 … keyN lockin: T T … T F Use • Shared data: var lock : boolean := false; • Process code for m.e.: var key : boolean:repeat key := true; repeat Swap(lock, key); until (key == false); critical section lock := false; remainder sectionuntil false;

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

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

31. 4.1. Definitions same as integer 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;

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

33. 4.3. Ordering Processes • Establish a fixed order for two processes p1 and p2 , We set semaphore Order := 0. • If the desired order is p1-> p2, p2 should issue a wait(Order), and then wait until p1 issues a signal(Order).

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 • This approach is used for controlling access to a limited number of resources (e.g. N resources)

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. New Semaphore Data Type type semaphore = record value : integer; L : list of waiting-processes; end;

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. 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. 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. • Starvation occurs when a waiting process never gets selected to move into the critical region.

40. 4.7. Binary Semaphores • 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. 5. Synchronization Examples • 5.1. Bounded Buffer • 5.2. Readers and Writers • 5.3. Dining Philosophers

42. 5.1. Bounded Buffer (Again) bounded buffer ….. ….. 0 1 2 3 n-1 producer consumer write read

43. Implementation • 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. 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. Consumer Code repeatwait(full); wait(mutex); itemC := buffer[out]; out := (out+1) mod n;signal(mutex); signal(empty); . . . /* use itemC for something */ . . .until false;

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

47. Many Variations • 1. Don’t keep a reader waiting unless a writer is already using the shared data • writers may starve • 2. Don’t keep a writer waiting • readers may starve

48. Variation 1 • 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. Writer’s Code :wait(wrt);. . ./* writing is performed */. . .signal(wrt); :

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