Re: [boost] [thread] RFC standard proposed mutex, read-write mutex, condition

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).
>
> http://home.twcny.rr.com/hinnant/cpp_extensions/concurrency_rationale.html

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