Race condition

1. Race condition The scourge of parallel and distributed computing...

2. Race condition • When multiple processes compete for a non-sharable resource • With no synchronization there is a race to who claims/modifies the resource • Read-Modify-Write (safe) • Read-Modify-Read-Write-Modify-Write

3. Race condition (cont) mem Thread A Thread B reg := mem reg := reg + 8 mem := reg reg := mem reg := reg + 1 mem := reg

4. Race condition (cont) reg := mem reg := reg + n mem := reg The race to write to mem creates a wrong result.

5. Race condition (cont) reg := mem reg := reg + n mem := reg The update from process A is lost because it was not seen by B

6. Race condition (cont) reg := mem reg := reg + n mem := reg The two updates do not interact, result is as expected. By sheer luck, operations were serialized.

7. Change request #1 Change request #2 Change request #3 Non-serialized operations Resource

8. Serialized operations Resource Change request #3 Change request #2 Change request #1 • The resource is protected by a mechanism which • enforces serial access to it: • Operating system • Database manager • Programming language synchronization

9. Synchronization • Only one process may execute the critical section of code • Acquire exclusive rights • Execute critical section • Release exclusive rights

10. Synchronization ... acquire_permission(s); reg = mem; reg = reg + n; mem = reg; release_permission(s); ... The entity s controls access to mem.

11. Synchronization • Semaphore – guards n resources • Any thread can return a resource • Mutex – guards 1 resource • Only the currently owning thread can return the resource • Threads block until the resource is granted

12. Semaphore • Counts the nof available resources • Acquire: decrement, Release: increment • No allocation or identification of resources • An atomically modifiable counter • Race conditions over the semaphore are prevented by • virtual machine / pgm language interpreter • operating system • hardware

13. Semaphore caveats • Processes (i.e. programmers) must follow the protocol and not: • Forget to return a resource after use • Return a resource that was not requested • Hold a resource for too long • Use a resource anyway

14. Mutex • A binary semaphore (one resource) • The process acquiring the resource is the only one that can return it (ownership) • The synchronized keyword in Java use any object as a monitor (a kind of mutex).

15. Monitor • A mutex with a thread queue • Threads queue for the mutex • Threads can yield the resource (wait) • Threads can alert other threads (notify) • In Java, every object has a monitor • The synchronized keyword

16. Unsharable resources • Process memory (part of) • Files • Databases • Printers, scanners, cameras, modems

17. Deadlock • Processes wait forever for all required resources to be released Waiting for R1 to be released R1 P1 P2 R2 Waiting for R2 to be released

18. Livelock • Processes attempt to break the deadlock by time-out and release, but no-one wins Waiting for R1 to be released R1 P1 P2 R2 Waiting for R2 to be released

19. Further fun reading • Dijkstra, The Dining Philosophers problem • Chandy/Misra solution to DPh problem • Producer-consumer problem • Sleeping barber problem • Readers-writers problem