Two Theads, One Shared Variable Two threads updating shared variable amount T 1 wants to decrement amount by $10K Thread Synchronization: T 2 wants to decrement amount by 50% Foundations T 1 T 2 . . . . . . amount := amount - 10,000; amount := amount * 0.5; . . . . . . amount = 100,000 What happens when T 1 and T 2 execute concurrently? 1 2 Two Theads, One Two Theads, One Shared Variable Shared Variable T 2 Might execute like this: But might also . . . T 2 execute like this: r2 := load from amount T 1 . . . r2 := load from amount . . . T 1 r2 := 0.5 * r2 r1 := load from amount store r2 to amount . . . r1 := r1 - 10,000 . . . . . . store r1 to amount r1 := load from amount . . . r2 := 0.5 * r2 r1 := r1 - 10,000 store r2 to amount store r1 to amount amount = 50,000 . . . amount = 40,000 . . . One update is lost! Wrong – and very hard to debug Or viceversa: T 1 and then T 2 amount = 45,000 3 4
Race Conditions: Race Conditions Hard to Debug Timing dependent behavior involving shared state Only some interleavings may produce a bug Behavior of race condition depends on how But bad interleavings may happen very rarely threads are scheduled! program may run 100s of times without generating one program can generate exponentially an unsafe interleaving many schedules or interleavings Compiler and processor hardware can reorder bug if any of them generates an instructions undesirable behavior All possible interleavings should be safe! 5 6 Therac-25 Therac-25 [1982] Old system used a hardware interlock Computer-controlled radiation therapy machine Lever either in the “electron-beam” or “x-ray” position New system was computer controlled Safety critical system with software interlocks Much went wrong: A synchronization failure triggered when competent nurses they let state of element A determine allowed used back arrow to change the data on the screen “too states for element B quickly” Ex: elevator cannot Engineers reused software from older models move with doors open it was buggy, but hardware interlocks masked the bugs The system noted a problem and halted X-beam, displaying Beam controlled entirely “MALFUNCTION” followed by obscure error code 54 through a custom OS technician resumed treatment
Therac-25 Outcome Aye, there’ s the rub… Patients received over 100x the recommended dose OS virtualizes resources of radiation Virtualizing a resource requires managing Three patients died of radiation overdose concurrent accesses Many cancer patients received inadequate data structures must transition between treatment consistent states People died because a programmer could not write Atomic actions transform state indivisibly correct code for a concurrent system can be implemented by executing actions 38 Year Later…. Now what? within a critical section 10 Edsger’ s perspective Take a walk on the wild side… Testing can only prove the presence of bugs … Lou Reed, 1972 … not their absence! 11 12
Properties Safety properties Property: a predicate that is evaluated over a “Nothing bad happens” run of the program (a trace) No more than processes are simultaneously in the k “every message that is received was critical section previously sent” Messages that are delivered are delivered in FIFO order No patient is ever given the wrong medication Not everything you may want to say about a Windows never crashes program is a property: A safety property is “prefix closed”: “the program sends an average of 50 messages in a run” if it holds in a run, it holds in its every prefix 13 14 Liveness properties A really cool theorem “Something good eventually happens” A process that wishes to enter the critical section eventually does so Every property is a combination of a Some message is eventually delivered safety property and a liveness property Medications are eventually distributed to patients (Alpern & Schneider) Windows eventually boots Every run can be extended to satisfy a liveness property if it does not hold in a prefix of a run, it does not mean it may not hold eventually 15 16
Recommend
More recommend
