httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthieu Estrade <mestr...@apache.org>
Subject Re: util_ldap [Bug 29217] - Remove references to calloc() and free()
Date Fri, 11 Jun 2004 21:05:56 GMT
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/)
>


Mime
View raw message