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