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