apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: apr_pools and thread safety
Date Thu, 30 Jun 2005 14:55:41 GMT
Sander Striker wrote:
> E Holyat wrote:
>> What if one thread destroys the allocator while this function is 
>> trying to dereference it.
> That means you have lifetime issues and that is considered a bug in your
> application.  You should make sure the allocator lives longer than the
> pools allocating out of it.
>> No matter what, you are going to lock in 99% of the time,
> The number is probably high, but I don't know how high.
>> why not be safe and lock it before dereferencing it.
> At the time I tried to make sure we never took out the mutex when not
> 99% sure we were going to use it, due to performance reasons.
>> Besides if you are going to fall into an if and wait on a mutex, 
>> shouldn't you check the if statement again too?  What is the purpose 
>> of the if statement when by the time a thread acquires the mutex, the 
>> if statement may no longer evaluate to TRUE?
> The if statement doens't need to be reevaluated because the code that
> is executed contains the same conditions as the if statement.  It may
> not directly be obvious, since the code is fairly dense, but this should
> and AFAIK is, the case.
> The important part is that there is no race condition leading to your
> NULL bug.  Do you agree that so far there is none?

Actually, I'm not sure about that.  IIRC there is some platform specific 
magic that needs to happen (memory barriers and so forth) to make double 
checked locking (the idiom you're using here) work correctly on all 
platforms.  I know that the double checked locking impl we had at my 
previous job needed some special stuff to make it work correctly all the 
time on alpha for example.  I can't recall all the details, but 
searching for double checked locking c/c++ might reveal some details...


View raw message