From Martin post: &quot;However, the storage server remembers that it has already processed a write with a higher token number (34), and so it rejects the request with token 33.&quot;<p>This is not eventual consistency, this is refusing any new write with ID &lt; past_ID, which requires linearizability.<p>Second, about eventual consistency, the Token ID even when increasing may not be casually related with the work performed while the lock is hold. if you need just a <i>random</i> order when there are concurrent accesses, you can lexically order the random token IDs, for what is worth.<p>Compare &amp; Swap: could you argument that? If you want to avoid races in a read-modify-write scenario, you can set the  token, do your work, and only write if the token is still the same, so that if your write succeed is because the state of the shared resource is still the same to when you started operating on it.