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