Ticket Lock
Only one r-m-w per acquire
Two counters per lock (next_ticket, now_serving)
- Acquire: fetch&inc next_ticket; wait for now_serving == next_ticket
- atomic op when arrive at lock, not when it’s free (so less contention)
- Release: increment now-serving
Performance
- low latency for low-contention - if fetch&inc cacheable
- O(p) read misses at release, since all spin on same variable
- FIFO order
- like simple LL-SC lock, but no inval when SC succeeds, and fair
- Backoff?
Wouldn’t it be nice to poll different locations ...