Linked by Thom Holwerda on Fri 7th Sep 2007 19:38 UTC, submitted by koki
Thread beginning with comment 269749
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
The message queues share the window lock in BeOS. Those are implicitly there as Lock A and B in his example, and are taken care of for you by the API in this case.
I'm not familiar with the BeOS api, but if they are indeed the same locks as in his example (lock A and lock B), his proposed solution wouldn't even work and would deadlock too.
I'm not familiar with the BeOS api, but if they are indeed the same locks as in his example (lock A and lock B), his proposed solution wouldn't even work and would deadlock too.
Actually they wouldn't, they're recursive locks. The way he demonstrates is in fact the way it works when you're working with that API.






Member since:
2005-09-14
While his solution solves the problem, it introduces more complexity into the code and perhaps more importantly it adds yet another lock (lock for each message queue which he doesn't show in the article but would be required). He also doesn't follow his own advice of "hold a lock for as short of a time as possible". Invalidate() doesn't require holding the data lock so he shouldn't call it while holding the lock.
The message queues share the window lock in BeOS. Those are implicitly there as Lock A and B in his example, and are taken care of for you by the API in this case.
Edited 2007-09-08 06:14 UTC