1 / 14

Race Conditions

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

nickan
Télécharger la présentation

Race Conditions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related