Race Conditions
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
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
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
…
hits = hits + 1;
…
• What happens when two threads execute concurrently?
some slides taken from Mendel
Rosenblum's lecture at Stanford
Shared counters
• Possible result: lost update!
hits = 0
T1
time
read hits (0)
hits = 0 + 1
hits = 1
T2
read hits (0)
hits = 0 + 1
• One other possible result: everything works.
 Difficult to debug
• Called a “race condition”
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
Race conditions
Process a:
while(i < 10)
i = i +1;
print “A won!”;
Process b:
while(i > -10)
i = i - 1;
print “B won!”;
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
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
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, …
T1
T2
hits[1] = hits[1] + 1; hits[2] = hits[2] + 1;
– 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!
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
Revisiting Race Conditions
Process a:
while(i < 10)
i = i +1;
print “A won!”;
Process b:
while(i > -10)
i = i - 1;
print “B won!”;
– Who wins?
– Will someone definitely win?
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?
Process 1
CS1
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.
Solution Structure
Shared vars:
Initialization:
Process:
...
...
Entry Section
Critical Section
Exit Section
Added to solve the CS problem
Sleeping Barber Problem