🗒️ Basics

• Critical Section is the piece of code for which we need to ensure only at most one process has access to it/is executing it at all times
• Processes can ask to enter() , run() and exit() the CS
• On a single machine, all processes are running on one OS, so mutual exclusion is easy using semaphores, mutexes, conditional variables, synchronization barriers, etc.

Requirements for Mutual Exclusion

• Safety - at most only 1 process executes the CS
• Liveness - every request to the CS is granted (eventually at least)
• Ordering - requests are granted in order or with some reasoning to the order

⏺️ Central

• Elect central master
• Queue of requests are sent to master
• Process with access to CS has a special token → hold onto it while in CS → send back to leader once done

Analysis

• Safety is met
• Liveness is met is process returns key before failure
• FIFO ordering at the master

Problem is that master is SPoF!

⭕ Ring-based

• Token is shared across all processes
• If you have the token and don’t need it → pass it along
• If you hav the token and need it → use it and then pass it along

Analysis

• Safety is met
• Liveness is given because token keeps looping till it reaches the requesting process, failures need to be accounted for

Problem: delays in access to CS still exist, at worst-case need to wait O(N) messages till token is passed back to you

👰🏽‍♀️ Ricart-Agrawala

• No token, relies on causality and multicast
• Indy’s analogy is to think about this like an Indian wedding - a process needs EVERYONES approval before entering CS