Edited 3/27/2012 to explain selection of answer: After giving this some more thought, I have come around to William Morris' view (see accepted answer) that this is basically the wrong approach. I am not totally convinced that it's impossible to implement this cache without locking, but I am convinced that it is quite hard. This is code I wrote several years ago and I now see it as an example of premature optimization. Since this cache is used a lot, I wanted to avoid mutexes. However I think the best thing to do now is to take a step back, take another look at what motivated this data structure, and think about a better solution.
I am trying to implement a shared cache for arrays. It must support two operations: set(owner, idx, value) and fetch(owner, idx) where idx
is the index into the array and owner
is an opaque handle to an owning object -- fetch(owner_1, idx)
should return the value stored by set(owner_1, idx)
only if the owner
argument matches. The cache must be thread - safe but I do not want to rely on locking, i.e. mutexes. Failure in looking up cached values is fine - it is OK and expected that other threads will overwrite existing values in the shared cache, in which case fetch
should just fail.