3 ms·
The problem with this solution is that if A writes Token_A to resource, and then A dies, then the resource can never be written to again. How do you avoid not n
by kapitalx 11y ago
The problem with this solution is that if A writes Token_A to resource, and then A dies, then the resource can never be written to again. How do you avoid not needing to time out the 'curr_lock'
- SomeCallMeTim 11y agoNo, when you acquire a lock, you are allowed to write to currlock immediately. It's AFTER you've done whatever processing you need to do that you do a compare-and-set transactional write that verifies no one else has written to currlock between your acquisition and the completion of your task.
- bogdando 11y agoThis pseudo code for random fence tokens should work as well safe as Martin's scenario with incremental IDs in the original article: try token=lock.aquire val=raw(shared, key, token) do_things awar(shared, key, val, token) except fail("Can't do!") finally lock.release 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'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). 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.