(tl;dr, I don&#x27;t think he does)<p>I&#x27;m also not a distributed systems expert, but this is how I interpreted the arguments. AntiRez is responding to the scenario where a client acquires a lock, hangs, a new client acquires a lock, and the old client comes back and tries to write something based off of a now stale lock. As demonstrated in this image [0]<p>So the random token ensures that even though many clients may &quot;think&quot; they have a lock, only up to a single client can ever actually have one. The write in the diagram which corrupts the database shouldn&#x27;t happen, because you&#x27;ll need to check that your lock token matches the service. [1] (excuse the terrible MSPaint modifications).<p>Which covers the common cases of lock timeout. But the clients aren&#x27;t the only part of the system that can violate the mutex. Martin seems to have already thought of this rebuttal:<p><pre><code>    You cannot fix this problem by inserting a check on the lock expiry just before writing back to storage. Remember that GC can pause a running thread at any point, including the point that is maximally inconvenient for you (between the last check and the write operation).
    [ ... ]
    If you still don’t believe me about process pauses, then consider instead that the file-writing request may get delayed in the network before reaching the storage service. Packet networks such as Ethernet and IP may delay packets arbitrarily
</code></pre>
And I don&#x27;t believe AntiRez answers this (or I&#x27;m not understanding when they do :P ). Even if a client makes a write-request at a perfectly valid point in time, when they own the lock, how do I know that by the time the write-request reaches storage, that the lock is still valid? The difference boils down to &quot;redlock guarantees requests are sent during a valid lock&quot;, but not &quot;redlock guarantees requests transact during a valid lock&quot;<p>Martin&#x27;s fix [2] is similar to the token method suggested, except: A) the write-if-token-matches logic is handled directly by the storage layer. B) It uses an auto-incrementing token.<p>He spends a few paragraphs making the point that redlock cannot generate good fencing tokens, because it has no good auto-increment consensus. But I don&#x27;t see how a random token is any worse than an incrementing one if you&#x27;re just going to straight up reject requests where the token doesn&#x27;t match. Antirez addresses this, without addressing A.<p>I would also really like someone to correct me if I&#x27;m missing something. The Redlock implementations are very bare-bones with tests or examples of how to actually use them. The Ruby library has a more &quot;advanced&quot; example, which says this at the point where they try writing to the file system:<p><pre><code>                # Note: we assume we can do it in 500 milliseconds. If this
                # assumption is not correct, the program output will not be
                # correct.
</code></pre>
Which doesn&#x27;t give me good faith in this...<p>[0] <a href="http:&#x2F;&#x2F;martin.kleppmann.com&#x2F;2016&#x2F;02&#x2F;unsafe-lock.png" rel="nofollow">http:&#x2F;&#x2F;martin.kleppmann.com&#x2F;2016&#x2F;02&#x2F;unsafe-lock.png</a><p>[1] <a href="http:&#x2F;&#x2F;i.imgur.com&#x2F;8rezAaX.png" rel="nofollow">http:&#x2F;&#x2F;i.imgur.com&#x2F;8rezAaX.png</a><p>[2] <a href="http:&#x2F;&#x2F;martin.kleppmann.com&#x2F;2016&#x2F;02&#x2F;fencing-tokens.png" rel="nofollow">http:&#x2F;&#x2F;martin.kleppmann.com&#x2F;2016&#x2F;02&#x2F;fencing-tokens.png</a><p>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;antirez&#x2F;redlock-rb&#x2F;blob&#x2F;master&#x2F;example2.rb" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;antirez&#x2F;redlock-rb&#x2F;blob&#x2F;master&#x2F;example2.r...</a>