>That's bad already.  At any time when there are n threads with a
>"handle" to a cache object, refcount ought to be n in order to be able
>to free it when refcount goes to zero.
 
>Unless:
 
>Condition 1) a mutex is held between the time that a thread gets a
>handle to the cache object and when the thread increments the refcount
>to reserve its handle
>*AND*
>Condition 2) Logic like that in decrement_refcount() which checks for
>refcount == 0 holds the very same mutex when it decrements and checks
>for refcount == 0, in order to insure that there are no other threads
>which are holding the mutex and are about to increment refcount.
In the current case, when calling memcache_cache_free(), the thread
hold the mutex, it was acquired back in create_entity() before doing
the new insertion/ejection.
For decrement_refcount(), the increase was done under the protection
of the same mutex, but the decrease is not currently protected and
it looks like it might need that step.
As far as performance, I currently don't see any slow down on my
box, but will run longer tests tomorrow morning.
 
Should I commit to 2.1 and add an entry in the status file for the
2.0 branch? I will like to see that fixed in time for 2.0.51 (if there
is an rc3).
 
JJ