Hi,
I am not sure about what i will say, but i think all these mutex are broken.
when i did that, i think i used apr_thread_mutex_create which use a pool (st->pool) which is the server pool.
This function is to use in a child, not between all forked child.
When it create the mutex, it do a apr_pcalloc to init the mutex struct, and only a pointer to the mutex is in the shared memory.
In worker mode, after this mutex creation, there is the fork step, and there, i think each forked child will have his own memory for the mutex struct.
So it will do many race condition on data in shm when locking the mutex.
I will look this week end if i say bullshit or not.
Matthieu
Greg Marr wrote:
At 12:33 PM 6/11/2004, William A. Rowe, Jr. wrote:
The proper logic to add to a cache is
wrlock test if exists again add element unlock
because there is a race condition in the logic below
rdlock test if the element exists >> race is here, prior to wrlocking, another thread may wrlock->insert promote to wrlock insert unlock
Wow, how about that. I just (as in within the last hour) read an article in the July issue of DDJ[1] that talked about replacing Singleton (WRowe's second example) with with Double-Checked Locking (WRowe's first example) and the problems that still exist because of compiler optimization.
What it boils down to is if this:
wrlock test if exists again add element unlock
can be broken down as this:
wrlock test if exists again allocate element fill in element insert element unlock
then the compiler may optimize this as:
wrlock test if exists again allocate element insert element >> race is here, prior to filling in element, another thread may >> read element, and use element that hasn't been filled in yet. fill in element unlock
Does the "add element" step guarantee that it won't insert the element into the cache until it is fully constructed, no matter what the optimizer does to the code?
Of course, this is only Part I of the article, Part II isn't until the August issue.
[1] Dr. Dobb's Journal, www.ddj.com (http://www.ddj.com/articles/2004/0407/)
