FM12 — Split-Brain: two processes both believe they hold the lock. This happens when TTL expires while the lock holder is paused. Process A holds the lock, pauses for longer than the TTL, and process B acquires the lock. Process A resumes, does not check whether the lock is still valid, and both A and B are in the critical section simultaneously. Fencing tokens prevent the damage from this scenario; they do not prevent the scenario itself.
FM5 — Latency Amplification from Lock Contention. When many workers compete for the same lock, each waits behind all others. If the lock-holder’s operation takes 500ms and 50 workers are waiting, the last worker waits 25 seconds. Lock contention is latency amplification applied to the entire queue of waiters. Diagnosis: measure lock wait time separately from lock hold time. If wait time dominates, the lock is the bottleneck.
Dead lock across two resources. Process A holds lock-1 and waits for lock-2. Process B holds lock-2 and waits for lock-1. Both wait forever. Distributed deadlock is harder to detect than single-machine deadlock because there is no kernel to inspect the lock graph. Prevention: always acquire multiple locks in a consistent order (lock with smaller ID first).
Lock renewal failure. Long-running operations need to renew the lock before TTL expires. If the renewal request fails — network hiccup, lock service overload — the lock expires mid-operation. Renewal adds complexity and a second category of failure: the operation must handle lock expiry, not just lock acquisition failure.