httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
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
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).

Mime
View raw message