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