apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: SMS lock on demand WAS: RE: Possible race condition...
Date Mon, 02 Jul 2001 23:05:25 GMT
[...]
>> The child thread is register in the parent thread. So, in the case of
>> the first created thread, a lock will be created. This does not happen
>> in the stub.
>
> That eliminates the first race condition, but not the second.  
> Consider this
> usage:
>   * There are two global SMSs, sms1 and sms2.
>   * Two threads, p1 and p2, are created with sms1 as the SMS supplied to
>     apr_thread_create.
>   * Prior to the creation of p1 and p2, sms2 is unused.
>   * p1 creates a child thread, c1, and passes sms2 as the SMS for
>     apr_thread_create to use.
>   * p2 creates a child thread, c2, and passes sms2 as the SMS for
>     apr_thread_create to use.
> 
> During the last two steps, we're vulnerable to the lock creation
> race condition.

Ok, I can see that. I must say though that anybody who is actually building
an application like this is asking for trouble. Tell me, why would
there need to be 2 global smss that are both used to pass in as a parent
to thread creation. That is very awkward...
 
> As far as I know, this isn't a case that will ever happen in Apache,
> but it's possible in APR based apps in general.  I guess there are
> two ways to solve it: 1) add code to defend against the race condition,
> or 2) impose a convention that says that p1 and p2 must register
> themselves with sms2 before they're allowed to create any other
> threads that use it.

Actually, they need to anyway. When they are _using_ an sms, which
they are, in this case sms2, by passing it to apr_thread_create(). In that
function sms2 is used to allocate the thread structure. This all takes
place in thread p1/p2. p1 and p2 should have registered themselves with
sms2 prior to using it.

> --Brian

Sander


Mime
View raw message