This pseudo code for random fence tokens should work as well safe as Martin&#x27;s scenario with incremental IDs in the original article:<p>try<p><pre><code>  token=lock.aquire

  val=raw(shared, key, token)

  do_things

  awar(shared, key, val, token)
</code></pre>
except<p><pre><code>  fail(&quot;Can&#x27;t do!&quot;)
</code></pre>
finally<p><pre><code>  lock.release
</code></pre>
Where a shared object has:
1) a key to store a value being changed in the critical section; 2) a currlock to store a random fence token associated with a lock.
The raw reads the shared key&#x27;s value after the currlock was written to the shared object.
The awar does an atomic write of the value to the key, only if the currlock has an expected token (i.e. is unchanged).<p>When things go wrong, the do_things may be executed more than once, in parallel, but the key is safe and guaranteed to have no lost updates to its value.