Yes you are quite right, and when I looked in my egdb driver code that is exactly how I did it. I shouldn't rely so much on my memory!Why do you need to lock the cache during "decode position's WLD value" ? Isn'it possible to first update LRU links and unlock immediatly the cache like this :
I'm not sure why you are trying to minimize the number of cache locks at the expense of having less cache buffers full of data, because the cache locks are brief and therefore do not have much affect on performance. Let's say that on average your data cache is only 85% full. If instead it was always 100% full like mine is, doesn't that mean that you would on average have fewer cache misses and fewer disk reads?Damy implementation is completetly different because I wanted to optimise the number of cache locks.
The main point if the following : suppose that you have an infinity entries for your cache. That means that you never need to replace an old block by a new one. As a consequence you do not need to handle a LRU link and you never need to lock the cache.
That is the idea in Damy : as long as the cache is not full the cache is never locked. When the cache becomes full I lock the cache in order to remove about 25% of the cache and then I unlocked the cache until it becomes full again. As you see, in real real game it may happen that the cache is never locked !
-- Ed