[boost] Re: Boost.Threads: Do we need all those mutexes?

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-06 07:36:49

Matthew Vogt wrote:

> Michael Glassford <glassfordm <at> hotmail.com> writes:
> 
> 
>>I agree. That's why I've so far only provided the Boost.Threads 
>>read/write lock try_promote() and timed_promote() methods (though you 
>>can, of course, get the latter to deadlock by using infinite times), and 
>>no promote() method. You could make a promote() method that throws if it 
>>can't promote, as you suggest below, but I don't like the idea much.
>>
> 
> 
> Why don't you like the exception?  I'll admit immediately to not having given
> this much thought, but the exception seems appropriate to a coding pattern
> based on RAII, since it gives simple control flow back to a user-chosen 
> failure handling point, freeing any previously taken locks.

To me, it just feels like the wrong way to be notified that a lock 
promotion failed so you have to do something else--a try_promote() seems 
much better for this. However, if people really wanted a throwing 
promote(), I'd add it.

> ALso, boost.thread already defines the lock_error exception for lock failure.

Yes, it does. Currently it's used for cases where you try to perform an 
operation that is invalid for the current state of the lock (e.g. 
unlocking a lock that isn't locked and vice versa, the threading API 
returns an error when you try to lock a mutex, etc.). Since trying to 
promote a read-lock isn't really invalid, throwing a lock_error would be 
an extension of its current meaning; but if that were really a problem, 
a new exception could be defined, of course.

Mike