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