On 8/20/07, Howard Hinnant <howard.hinnant@gmail.com> 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