Boost logo

Boost :

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
"owns what?".

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
tools instead.

Are there any plan to add transfer_lock, and any other such generic
algoirthms you have lying around, to the proposal as well?

Zach Laine

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