apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: Possible race condition in pools WAS: RE: Thoughts on locks
Date Thu, 28 Jun 2001 21:02:56 GMT
> >I guess a thread that registers its interest in a child SMS is by
> >definition 'interested' in all ancestors of that SMS...

Yes, exactly right :)

> 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.

Yes, the implementation is straightforward, but not how you paint it. It
is actually a lot simpler. I'll present this soon in code. [please be
patient :) ]

> 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 should just fail.)

That would be an option, but doing this dynamically isn't that difficult
and most of the time the developer doesn't need to worry about it.

> --Brian

Sander


Mime
View raw message