apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: Possible race condition in pools WAS: RE: Thoughts on locks
Date Thu, 28 Jun 2001 20:21:08 GMT
Cliff Woolley wrote:

>On Thu, 28 Jun 2001, Brian Pane wrote:
>>I like the concept of registering threads' "interest" in an sms.  But how do
>>you handle the need for synchronization in a parent sms?  E.g., if an app
>>creates an global sms and then two different threads create sms_block
>>instances with the first sms as their parent, the two child sms_block
>>instances don't need to do any locking but the parent sms does.  A
>>reference count isn't sufficient to determine whether locking is needed
>>in the parent; it really needs to know the number of distinct thread
>>IDs registered with its children.
>I guess a thread that registers its interest in a child SMS is by
>definition 'interested' in all ancestors of that SMS...
The more I think about it, the trickier the "register interest" paradigm
looks.  The implementation is straightforward: each SMS with children
just needs to keep a set (hash table etc) of the thread IDs of all threads
that have registered an interest in any descendant SMS; and if the number
of thread IDs in that set is greater than or equal to 2, most operations on
the SMS need to be protected by mutex locks.  However, updating the
set (as children are added/destroyed and threads register/unregister their
interest in descendant SMSes) and checking the count of things in the set
are both operations susceptible to race conditions.  So I think you'd need
to use locks anyway, for any SMS with children...which arguably defeats
the motivation for doing the registration-of-interest model.

It might be a whole lot easier to just designate each SMS as cross-thread
or not-cross-thread when it's created, and wrap "if cross-thread then lock"
logic around all vulnerable code.  (And if an SMS is created as cross-thread
and it has a non-null parent SMS that's not cross-thread, the creation 
just fail.)


View raw message