Boost logo

Boost :

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

Matthew Vogt wrote:

> Michael Glassford <glassfordm <at>> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at