Understanding Race Conditions in Computer Systems

1. Race Conditions

2. Isolated & Non-Isolated Processes • Isolated: Do not share state with other processes • The output of process is unaffected by run of other processes. • Scheduling independence: any order  same result • Non-isolated: Share state • Result can be affected by other simultaneous processes • Scheduling can alter results • Non-deterministic: same inputs != same result • Eg. You and your SO have separate vs. joint accounts

3. Why sharing? • Cost • One computer per process • Speed • Simultaneous execution • Information flow • Assembler needs output of compiler and so on… • Modularity • Break code into components

4. Two threads, one counter Popular web server • Uses multiple threads to speed things up. • Simple shared state error: • each thread increments a shared counter to track number of hits • What happens when two threads execute concurrently? … hits = hits + 1; … some slides taken from Mendel Rosenblum's lecture at Stanford

5. T2 Shared counters • Possible result: lost update! • One other possible result: everything works.  Difficult to debug • Called a “race condition” hits = 0 T1 time read hits (0) read hits (0) hits = 0 + 1 hits = 0 + 1 hits = 1

6. Race conditions • Definition: timing dependent error involving shared state • Whether it happens depends on how threads scheduled • Hard to detect: • All possible schedules have to be safe • Number of possible schedule permutations is huge • Some bad schedules? Some that will work sometimes? • they are intermittent • Timing dependent = small changes can hide bug

7. Race conditions If i is shared, and initialized to 0 • Who wins? • Is it guaranteed that someone wins? • What if both threads run on identical speed CPU • executing in parallel Process a: while(i < 10) i = i +1; print “A won!”; Process b: while(i > -10) i = i - 1; print “B won!”;

8. Do race conditions affect us? • Therac-25 • A number of others: • Google for “race condition” vulnerability • Windows RPC service race condition • Two threads working on same piece of memory • Sometimes, one frees variable and then other tries to access • FreeBSD PPPD: could be used to get root privileges • Linux i386 SMP: you could become root (January, 2005) • Memory management on multiprocessor machines • 2 threads sharing VM request stack expansion at the same time

9. T2 T1 hits[1] = hits[1] + 1;hits[2] = hits[2] + 1; Dealing with race conditions • Nothing. Can be a fine response • if “hits” a perf. counter, lost updates may not matter. • Pros: simple, fast. Cons: usually doesn’t help. • Don’t share: duplicate state, or partition: • Do this whenever possible! • One counter per process, two lane highways instead of single, … • Pros: simple again. Cons: never enough to go around or may have to share (gcc eventually needs to compile file) • Is there a general solution? Yes! • What was our problem? Bad interleavings. So prevent!

10. The Fundamental Issue: Atomicity • Our atomic operation is not done atomically by machine • Atomic Unit: instruction sequence guaranteed to execute indivisibly • Also called “critical section” (CS) • When 2 processes want to execute their Critical Section, • One process finishes its CS before other is allowed to enter

11. Revisiting Race Conditions Process b: while(i > -10) i = i - 1; print “B won!”; Process a: while(i < 10) i = i +1; print “A won!”; – Who wins? – Will someone definitely win?

12. Critical Section Problem • Problem: Design a protocol for processes to cooperate, such that only one process is in its critical section • How to make multiple instructions seem like one? CS1 Process 1 Process 2 CS2 Time  Processes progress with non-zero speed, no assumption on clock speed Used extensively in operating systems: Queues, shared variables, interrupt handlers, etc.

13. Solution Structure Shared vars: Initialization: Process: . . . . . . Entry Section Critical Section Exit Section Added to solve the CS problem

14. Sleeping Barber Problem