>Looking more closely at the implication of the submitted patch, >I don't think we want to lock decrement_refcount() with a >global mutex affecting the whole cache. Yes, it fixes the double free,
I think you should commit your last patch ASAP, and then somebody can work out a redesign of the object management, one working design can be replaced with another. For a more granular mutex, there could be an array of mutexes with one chosen based on the hash value? Use that mutex in place of a global mutex. >I am trying to find a solution using the current atomic APIs, >but have not been succesfull so far. If someone has a better >idea, I am more than open to try it. I believe that the solution has to involve mutexes, as cache_cache.c doesn't (can't?) increment a mutex as soon as a thread gets a handle to an object. A solution using more advanced atomic APIs (e.g., compare-double-and-swap) could be useful if the cache itself were substantially redesigned, right? Do stuff like eliminate findability of entries without actually freeing the entry, adding it to a queue of pending operations, then the last searcher leaving the table has to simultaneously set the searcher refcount to zero and dequeue the pending operations, then process those pending operations. --/-- Unfortunate that the current design requires a mutex to be held during increment/decrement yet we use atomic operations on the refcount. Those atomic operations result in lock/modify/unlock for many of us (using the portable atomics).
