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

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

Race condition (cont) reg := mem reg := reg + 1 mem := reg reg := mem reg := reg + 8 mem := reg mem Thread AThread B

Race condition (cont) reg := mem reg := reg + n mem := reg Timereg of Areg of Bmem (reg:=mem) 31 (reg:= reg+1) 8 (reg:= reg+8) 4? The race to write to mem creates a wrong result.

Race condition (cont) reg := mem reg := reg + n mem := reg Timereg of Areg of Bmem (reg:=mem) 0 31 (reg:= reg+1) 0 (reg:=mem) 48 (reg:= reg+8) 1 (mem:=A.reg) 58 (mem:=B.reg) 6 7 The update from process A is lost because it was not seen by B

Race condition (cont) reg := mem reg := reg + n mem := reg Timereg of Areg of Bmem (reg:=mem) 31 (reg:= reg+1) 41 (mem:=A.reg) 51 (reg:=mem) 69 (reg:= reg+8) 79 (mem:=B.reg) The two updates do not interact, result is as expected. By sheer luck, operations were serialized.

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

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

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

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

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

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

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

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).

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

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

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

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

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