Re: [boost] [thread] thread interruption semantics

From: Preston A. Elder (prez_at_[hidden])
Date: 2007-11-14 08:20:32

On Wed, 14 Nov 2007 12:27:44 +0000, Preston A. Elder wrote:

> This would be easily fixed by getting it to lock the internal lock on
> unlock (before the notify_all).  Doing so would mean that the notify_all
> could not happen until B is in the wait.

And now I think about it, it should probably be a notify_one - there is 
no point waking up all threads when only one will be able to acquire the 
lock after an unlock.  But then, I guess, since my class is templated, 
there might actually be a concept of lock sharing (read locks for 
example), so maybe I could be unlocking the writer, and then notifying a 
bunch of readers.  Hrrrm .. :)

This, of course, is assuming I had a 'view' on the shared_lock that would 
EITHER call lock_shared or lock() depending on my 'view'.  Hrm, another 
new though, should my lock be able to specify which function to call 
(try_lock / try_shared_lock / try_lock_upgrade) .. I love stream of 
conciousness moments ;)

PreZ :)