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? Sander
