apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: SMS lock on demand WAS: RE: Possible race condition...
Date Mon, 02 Jul 2001 23:16:05 GMT
Sander Striker wrote:

>>>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
>>  * 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...
It's definitely awkward.  I could see it happening, though, if
somebody builds a library based on APR that creates a global
SMS for thread creation, and then a third party uses this library
in an application that creates its own global SMS and uses it to
create additional threads within callbacks invoked by the library's
threads.  (I'm not claiming that this is a good design, but it's a
good test of the robustness of the registration model.  And it
looks like the model can handle this example properly, by
requiring that p1 and p2 register themselves with sms2 as
noted below.)

>>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.
Agreed.  And that resolves all the race conditions that
I was worried about.


View raw message