From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2007-08-21 16:41:12
On 8/20/07, Howard Hinnant <howard.hinnant_at_[hidden]> wrote:
> Here is a link to a reference implementation and a FAQ for mutexes,
> locks and condition variables I am currently anticipating proposing
> for C++ standardization (or subsequent TR).
The owns() name is a better selection than locked(), I agree. But
just as unique_lock<mutex>(mut, try_to_lock) is more readable than
unique_lock<mutex>(mut, true), I think owns_mutex_lock() or
owns_mutex() is better than owns(). When I first see "owns()" I think
That was the only thing I could think of to fault, looking at this
with my pickiest and most pedantic hat on. Over all, I think this
proposal is great. I particularly like these aspects:
- The divorcing of the mutexes, locks, and conditions from one
another, a la the STL container/algorithm distinction. As you point
out, this makes user-written replacements of these types possible in a
much more direct manner.
- The ability to add runtime checking to the mutexes/locks used with
conditions, via the one-argument condition ctor. Without this sort of
automatic checking, you're relegated to correctness by inspection.
Writing multithreaded code is hard enough; automated correctness
checks are always welcome.
- The condition memory overhead solution in Q17, for the reason you
state. If this sort of efficiency is not transparently possible with
the high-level tools, one may be forced/encouraged to use lower level
Are there any plan to add transfer_lock, and any other such generic
algoirthms you have lying around, to the proposal as well?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk