CS195Y Lecture 25

04/07/2017

---

Model Checking (2)

Last time

1. I want to enter the critical section by raising my flag.
2. I enter the critical period.
3. I do something in the critical section
4. I leave the critical section.
5. I say that I no longer want to enter the critical section by lowering my flag.

This protocol should prevent processes from being in the critical region at the same time. However, we have a failure of mutual exclusion because they can both enter the region before setting flag, run in lockstep, both end up in the same state.

What if we raise flag before checking the other's flag? Deadlock.

• Run a simulation: spin lock1.pml leads to timeout with both flags raised.
• Try: gcc -o pan pan.c; ./pan: no conflicts, but no progress (ends in invalid state).
• Trace: spin -t -p lock1.pml, gives an example of an instance of the algorithm with a deadlock.

How do we solve the problem of two people having their hands raised? Maybe there's a powerful third party who gets to select the next person to talk? Maybe people have different priorities. A convention for tie-breaking (the person who raises their hand first, etc) based on politeness.

Lock2

'victim' becomes interested in locks, waits for someone else to become interested and then let it go first (becomes the victim), then it runs. What if the next process never becomes interested? No progress.

Claim: if both processes are always interested, then this system always solves mutual exclusion and non-starvation.

• spin lock2.pml - runs forever
• ./pan - no errors/assertion violations/deadlock

In reality, processes aren't constantly trying to get access to the critical section and algorithm doesn't do well. Why doesn't our model reveal this bug? Need to give an option to the processes where they can not be interested: model being busy doing something else with a nondeterministic loop.

Still zero errors - no deadlocks. Need a more advanced property to check - linear temporal logic (ltl) - logic about what happens over periods of time. We want ensure that if the first process is ever the victim, eventually it will get access to the critical section

ltl zero_not_starved {
    always (victim == 0 -> eventually (in_crit[0]))
}

Try to verify again: (need to add -a to verify ltl property) ./pan -a. Found an error! Violates our ltl. The counter-example - process 1 is continuously not interested, never becomes the victim, process 0 never makes it to the critical region

Lock3: Peterson Lock

Uses flags and politeness. Uses politeness to break flag ties. Block until other process becomes the victim _or_ it puts its flag down. Claim: this algorithm ensures mutual exclusion and non starvation!

Spin gives us an example where process 0 is never allowed to go: scheduler can be evil (which no locking algorithm can prevent). Add '-f' for a fair scheduler: /.pan -a -f .