1. 1 Race Conditions/Mutual Exclusion Segment of code of a process where a shared resource is accessed (changing global variables, writing files etc) is called the Critical Section (CS)  If several processes access and modify shared data concurrently, the outcome can depend solely on the order of accesses (sans ordered control): Race Condition  In a situation involving shared memory, shared files, shared address spaces and IPC, how do we find ways of prohibiting more than 1 process from accessing shared data at the same time and providing ordered access? Mutual Exclusion (ME) [Generalization of the Race Condition Problems]

2. 2 Race Condition : concurrent accesses to shared memory next_file_to_print next_free_slot next print request A & B generate print jobs To print a file, both A and B enter f.n to spooler directory A (next_free_slot)  7 (reads “in”) A interrupted; B switches in (and then A comes back) B  reads in (7)A  next_free_slot (7) B  f.n slot 7A  f.n slot 7in = 7+1 = 8 A prints, B stuck

3. 3 Critical Regions Mutual exclusion using critical regions

4. 4 Critical Regions & Mutual Exclusion Four conditions need to hold to provide mutual exclusion 1. Unity/ME: No two processes are simultaneously in the CS 2. Fairness: No assumptions can be made about speeds or numbers of CPUs except that each process executes at non-zero speed 3. Progress: No process running outside its CS may block another process (from accessing the CS) 4. Bounded Waiting: No process must wait forever to enter its CS

5. 5 Potential ME Solutions: Interrupts Interrupt Masking (Disable Interrupts) –each interrupt has a priority level (ipl) –for each executing process, kernel maintains “current ipl” –incoming_interrupt > current_ipl  handle interrupt, else not For ME Enter CS Current_ipl  max_ipl ; disable interrupts CS Restore_ipl Exit CS  Restore_ipl lost? Process hangs  other processes blocked?  Multiproc: 1 CPU disabled, process from CPU 2 can come in meaning of “ipl” across processors?

6. 6 ME: Using Locks for Access? unlocked?  acquire lock enter CS done  release lock do non-CS

7. 7 ME: Lock Variables flag(lock) as global variable for access to shared section  lock = 0 ; resource_free  lock = 1 ; resource_in_use  Unix flags: locked (0,1); wanted Check lock; if free; set lock to 1 and then access CS  A reads lock(0); initiates set_to_1  B comes in before lock(1) finished; sees lock(0), sets lock(1)  Both A and B have access rights  race condition   Happening as “locking” (the global var.) is not an atomic action

8. 8 Process Alternation: ME with Busy Waiting A sees turn=0; enters CSB sees turn=0; busy_waits (CPU idle) A exits CS, sets turn =1B sees turn=1; enters CS B finishes CS; sets turn=0; A enters CS; finishes CS quickly; sets turn=1; B in non-CS, A in non-CS; A finishes non-CS & wants CS; BUT turn=1  A waits (Condition 3 of ME? Process seeking CS should not be blocked by a process not using CS!!! But, no race condition given the strict alternation!) Turn 0Turn 1

9. 9 Peterson’s Busy Waiting Sans Strict Alternation Process 0: other = 1; interested[0] = TRUE; turn = 0; interested[1] = FALSE; P0 exits call and gets CS Process 1: other = 0; interested[1] = TRUE; turn = 1; interested[0] = TRUE; loops Step 1: Step 2: turn is “global”var; written by last requester ? shared var

10. 10 Petersons ME (Alternate implementation) int turn; “turn” to enter CS boolean flag[2]; TRUE indicates ready (access) to enter CS do { flag[i] = TRUE; turn = j ; set access for next_CS access while (flag[j] && turn = = j); CS only if flag[j]=FALSE or turn = i CS flag[i] = FALSE; non-CS } while(TRUE); Work out that conditions of ME, Fairness, Progress, Bounded-Waiting Hold!!!

11. 11 Refresh: Race Conditions using Lock Variables flag(lock) as global variable for access to shared section  lock = 0 ; resource_free  lock = 1 ; resource_in_use  Unix flags: locked (0,1); wanted Check lock; if free; set lock to 1 and then access CS  A reads lock(0); initiates set_to_1  B comes in before lock(1) finished; sees lock(0), sets lock(1)  Both A and B have access rights  race condition   Happening as “locking” (the global var.) is not an atomic action

12. 12 Is finer granularity & speed possible at the HW level?  Provide “concurrency control” or “synchronizer” instructions  Make “test & set lock” as an atomic (“uninterruptible op”)

13. 13 ME with Busy Waiting: Atomic TSL Entering and leaving CS using TSL (HW Based) global variable! 0 =‘s unlocked

14. 14 Busy Waiting  Wasted CPU cycles (Busy-waiting locks  Spin locks) Some spin lock problems: “The Priority Inversion Case” –2 threads: H (high priority); L (low priority)… L not scheduled if H is there! –H runs whenever “ready” –L in CS; H gets “ready”; H busy-waits –BUT: L is not scheduled anytime H is running; so L is stuck in CS (cannot exit) while H loops forever (waiting for L to get out). –So does H really have high priority or is L over-riding it?  Is ME condition 4: Bounded Waiting holding? Can we use “block” or “sleep” state than busy-waiting?

15. 15 Sleep and Wakeup (Bounded Buffer PC) … but can have a fatal race condition!!! Shared fixed-size buffer - Producer puts info IN - Consumer takes info OUT

16. 16 Producer-Consumer: Sleep/Race Condition T1 T2 locks locked(1) unlocks locked(0) any req? locked(0) T2 tried locking, a little late. T1 wins … so T2 goes to sleep time taken for T2 to sleep T2 sleeping; misses call put “wanted” flag wakeup!

17. 17 Do Semaphores help? Do SW mechanisms exist for synchronization than HW TSL? Semaphores (S): Integer Variables [System Calls] –Accessible only through 2 standard atomic operations (i.e., operation must execute indivisibly) of: wait() signal()  Wait(S) { ; sleep while S 0 ; // no-op S--; }  Signal(S) { ; wakeup S++; } S can be an integer resource counter; If S is binary, it is called a “mutex” wait(0)  block if 0 wait(1)  decrement & progress (DOWN) signal(0)  increment and unblock (UP)

18. 18 ME using Semaphores do { wait (mutex);”mutex” variable initialized to 1 // critical section signal (mutex); // non critical section } while (TRUE); wait(0)  block if 0 wait(1)  decrement & progress (DOWN) signal(0)  increment and unblock (UP)