httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: Seg fault: Possible race conditions in mod_mem_cache.c
Date Fri, 10 Sep 2004 11:04:21 GMT
>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

>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).

View raw message