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

some slides taken from Mendel Rosenblum's lecture at Stanford

Two threads, one counterPopular 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;…

Shared counters• Possible result: lost update!

• One other possible result: everything works. Difficult to debug

• Called a “race condition”

hits = 0 + 1

read hits (0)

hits = 0 + 1read hits (0)

T1 T2

hits = 1

hits = 0

time

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

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

Race conditions

Process b: while(i > -10)

i = i - 1; print “B won!”;

Process a: while(i < 10)

i = i +1; print “A won!”;

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, …

– 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!

hits[1] = hits[1] + 1; hits[2] = hits[2] + 1;

T2T1

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 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?

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?

Processes progress with non-zero speed, no assumption on clock speed

Used extensively in operating systems:Queues, shared variables, interrupt handlers, etc.

Process 1

Process 2

CS1

Time

CS2

Solution StructureShared vars:

Initialization:

Process:. . . . . .

Entry Section

Critical Section

Exit Section

Added to solve the CS problem

Sleeping Barber Problem