Outline

1. Outline • Basic Synchronization Principles

2. Interacting Processes • Independent process • Cannot affect or be affected by the other processes in the system • Does not share any data with other processes • Interacting process • Can affect or be affected by the other processes • Shares data with other processes • We focus on interacting processes through physically or logically shared memory COP4610

3. Bounded-Buffer COP4610

4. Bounded-Buffer – cont. • Shared data typedef struct { ...... } item; itembuffer[n]; int in, out,counter; in =0; out=0; counter = 0; COP4610

5. Bounded Buffer – cont. • Producer process repeat … produce an item in nextp … whilecounter == n do no-op; buffer [in] = nextp; in = (in + 1) % n; counter ++; until false; COP4610

6. Bounded-Buffer - cont. • Consumer process repeat whilecounter == 0 dono-op; nextc = buffer [out]; out = (out + 1) % n; counter--; … consume the item in nextc … untilfalse; COP4610

7. Bounded-Buffer - cont. • If we let producer and consumer processes run concurrently, we may have wrong result • Note the simple-thread program • Each thread is working properly • However, the total balance is not kept COP4610

8. Bounded-Buffer - cont. • Suppose we have one producer and one consumer, the variable counter is 5 • Producer: counter = counter +1 P1: load counter, r1 P2: add r1, #1, r2 P3: store r2, counter • Consumer: counter = counter - 1 C1: load counter, r1 C2: add r1, #-1, r2 C3: store r2, counter COP4610

9. Bounded-Buffer - cont. • A particular execution sequence • P1: load counter, r1 • P2: add r1, #1, r2 --- Context switch ---- • C1: load counter, r1 • C2: add r1, #-1, r2 • C3: store r2, counter --- Context switch ---- • P3: store r2, counter • What is the value ofcounter? COP4610

10. Bounded-Buffer - cont. • A particular execution sequence • C1: load counter, r1 • C2: add r1, #-1, r2 --- Context switch ---- • P1: load counter, r1 • P2: add r1, #1, r2 • P3: store r2, counter --- Context switch ---- • C3: store r2, counter • What is the value ofcounter this time? COP4610

11. Bounded-Buffer - cont. • A particular execution sequence • C1: load counter, r1 • C2: add r1, #-1, r2 • C3: store r2, counter --- Context switch ---- • P1: load counter, r1 • P2: add r1, #1, r2 • P3: store r2, counter --- Context switch ---- • What is the value ofcounter this time? COP4610

12. Race Condition • Race condition • When several processes access and manipulate the same data concurrently, there is a race among the processes • The outcome of the execution depends on the particular order in which the access takes place • This is called a race condition COP4610

13. Traffic Intersections COP4610

14. Race condition updating a variable COP4610

15. Race condition timing chart COP4610

16. shared double balance; Code for p1Code for p2 . . . . . . balance = balance + amount; balance = balance - amount; . . . . . . balance+=amount balance-=amount balance Updating A Shared Variable COP4610

17. Execution of p1 Execution of p2 … load R1, balance load R2, amount Timer interrupt … load R1, balance load R2, amount sub R1, R2 store R1, balance … Timer interrupt add R1, R2 store R1, balance … Updating A Shared Variable – cont. COP4610

18. Simultaneous editing of a file COP4610

19. Race condition COP4610

20. The Critical-Section Problem • n processes all competing to use some shared data • Each process has code segments, called critical section, in which the shared data is accessed. • Problem – ensure that when one process is executing in its critical section, no other process is allowed to execute in its critical section, called mutual exclusion COP4610

21. The Critical-Section Problem – cont. • Structure of process Pi repeat entry section critical section exit section reminder section untilfalse; COP4610

22. Requirements for Critical-Section Solutions • Mutual Exclusion. • If process Pi is executing in its critical section, then no other processes can be executing in their critical sections. • Progress • If no process is executing in its critical section and there exist some processes that wish to enter their critical section, then the selection of the processes that will enter the critical section next cannot be postponed indefinitely. • Bounded Waiting • 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. COP4610

23. Solution through Disabling Interrupts • In a uni-processor system, an interrupt causes the race condition • The scheduler can be called in the interrupt handler, resulting in context switch and data inconsistency COP4610

24. Solution through Disabling Interrupts– cont. • Process Pi repeat disableInterrupts(); //entry section critical section enableInterrupts(); //exit section reminder section untilfalse; COP4610

25. Solution through Disabling Interrupts– cont. COP4610

26. Solution through Disabling Interrupts– cont. • This solution may affect the behavior of the I/O system • Interrupts can be disabled for an arbitrarily long time • The interrupts can be disabled permanently if the program contains an infinite loop in its critical section • User programs are not allowed to enable and disable interrupts directly • However, if the operating system can provide system calls, a user can use the system calls for synchronization • Called semaphores and related system calls COP4610

27. Software Attempt to Solve the Problem • Only 2 processes, P1 and P2 • General structure of process Pi(other process Pj) repeat entry section critical section exit section reminder section untilfalse; • Processes may share some common variables to synchronize their actions. COP4610

28. Algorithm 1 • Shared variables: • varturn: (0..1);initially turn = 0 • turn - i Pi can enter its critical section • Process Pi repeat whileturn idono-op; critical section turn := j; reminder section untilfalse; • Satisfies mutual exclusion, but not progress COP4610

29. Algorithm 2 • Shared variables • varflag: array [0..1] ofboolean;initially flag [0] = flag [1] = false. • flag [i] = true Pi ready to enter its critical section • Process Pi repeat flag[i] := true;whileflag[j] dono-op; critical section flag [i] := false; remainder section untilfalse; • Satisfies mutual exclusion, but not progress requirement. COP4610

30. Algorithm 3 • Combined shared variables of algorithms 1 and 2. • Process Pi repeat flag [i] := true;turn := j;while (flag [j] and turn = j) dono-op; critical section flag [i] := false; remainder section untilfalse; • Meets all three requirements; solves the critical-section problem for two processes. COP4610

31. Bakery Algorithm Critical section for n processes • Before entering its critical section, process receives a number. Holder of the smallest number enters the critical section. • If processes Pi and Pj receive the same number, if i < j, then Pi is served first; else Pj is served first. • The numbering scheme always generates numbers in increasing order of enumeration; i.e., 1,2,3,3,3,3,4,5... COP4610

32. Bakery Algorithm – cont. • Notation < lexicographical order (ticket #, process id #) • (a,b) < c,d) if a < c or if a = c and b < d • max (a0,…, an-1) is a number, k, such that k  ai for i - 0, …, n – 1 • Shared data varchoosing: array [0..n– 1] ofboolean; number: array [0..n – 1] ofinteger, Data structures are initialized to false and 0 respectively COP4610

33. Bakery Algorithm (Cont.) repeat choosing[i] := true; number[i] := max(number[0], number[1], …, number [n – 1])+1; choosing[i] := false; forj := 0 ton – 1 do begin whilechoosing[j] dono-op; whilenumber[j]  0 and (number[j],j) < (number[i], i) dono-op; end; critical section number[i] := 0; remainder section untilfalse; COP4610

34. Algorithm • Shared variables: • boolean lock;initially lock = FALSE • lock is FALSE  Pi can enter its critical section • Process P1 Process P2 repeat while (lock)dono-op; lock = TRUE; critical section lock = FALSE reminder section untilfalse; repeat while (lock)dono-op; lock = TRUE; critical section lock = FALSE; reminder section untilfalse; COP4610

35. Blocked at while p2 p1 lock = FALSE lock = TRUE Interrupt Interrupt Interrupt Busy Wait Condition shared boolean lock = FALSE; shared double balance; Code for p1Code for p2 /* Acquire the lock */ /* Acquire the lock */ while(lock) ; while(lock) ; lock = TRUE; lock = TRUE; /* Execute critical sect */ /* Execute critical sect */ balance = balance + amount; balance = balance - amount; /* Release lock */ /* Release lock */ lock = FALSE; lock = FALSE; COP4610

36. Synchronization Hardware • Test and modify the content of a word atomically (indivisibly) • The procedure cannot be interrupted until it has completed the routine • Implemented as a test-and-set instruction booleanTest-and-Set (boolean target) { boolean tmp tmp = target;target = true; return tmp; } COP4610

37. Mutual Exclusion with Test-and-Set • Shared data: boolean lock ; • Initially false • Process Pi repeat whileTest-and-Set (lock) dono-op; critical section lock = false; remainder section untilfalse; COP4610

38. Semaphores • Semaphore S – integer variable • can only be accessed via two indivisible (atomic) operations wait (S): whileS 0 dono-op;S := S– 1; signal (S): S := S + 1; COP4610

39. Example: Critical Section of n Processes • Shared variables • varmutex : semaphore • initially mutex = 1 • Process Pi repeat wait(mutex); critical section signal(mutex); remainder section untilfalse; COP4610

40. Shared Account Balance Problem Proc_0() { proc_1() { . . . . . . /* Enter the CS */ /* Enter the CS */ P(mutex);P(mutex); balance += amount; balance -= amount; V(mutex);V(mutex); . . . . . . } } semaphore mutex = 1; fork(proc_0, 0); fork(proc_1, 0); COP4610

41. Sharing Two Variables proc_A() { while(TRUE) { <compute section A1>; update(x); /* Signal proc_B */ V(s1); <compute section A2>; /* Wait for proc_B */ P(s2); retrieve(y); } } semaphore s1 = 0; semaphore s2 = 0; fork(proc_A, 0); fork(proc_B, 0); proc_B() { while(TRUE) { /* Wait for proc_A */ P(s1); retrieve(x); <compute section B1>; update(y); /* Signal proc_A */ V(s2); <compute section B2>; } } COP4610