Whoah, whoah, whoah, no:<p><i>1. Most of the times when you need a distributed lock system that can guarantee mutual exclusivity, when this property is violated you already lost. Distributed locks are very useful exactly when we have no other control in the shared resource.</i><p>In context, Sanfilippo seems to be arguing that providing monotonic logical timestamps or sequence numbers is futile, since a system that relies on locks that break is going to fail one way or another.<p>That is probably true, but wildly misses the point: when a sound system that relies on distributed locks fails, <i>it doesn&#x27;t silently corrupt data</i>. But that&#x27;s exactly what happens in the &quot;unfenced&quot; lock-breaking scenario Kleppmann describes.<p>There are worse things than crashing, is the point.<p><i>slightly later</i><p>The argument about storage servers taking fencing tokens being &quot;linearizable&quot; also seems flimsy: aren&#x27;t they &quot;linearizable&quot; (in whatever sense Sanfillippo means) in the case Kleppmann because <i>because the lock service arranges for them to be</i>? That&#x27;s functionality Kleppmann says is missing from Redlock.