Subject: [boost] [thread] On shared_mutex
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2010-11-28 15:52:52
Three years ago I wrote N2406 "Mutex, Lock, Condition Variable Rationale" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html) for the C++ committee in an attempt to explain the combined proposed std::mutex/std::unique_lock package and how it fit together with the tr2-targeted shared_mutex/shared_lock package. This paper also proposed an upgrade_mutex and upgrade_lock.
Since that time, the std-proposed stuff has been accepted with some name changes, and a reworking of the timed-locking interface. Additionally Anthony Williams has implemented much of the shared-locking functionality in boost (and done a very nice job with it).
That being said, I disagree with some fairly major design changes between N2406 and what is now in the boost library. Four of the major changes are:
1. upgrade_mutex has been dropped.
2. Some, but not all of the functionality in upgrade_mutex has been moved into shared_mutex.
3. Some of the upgrade_mutex functionality is missing completely. The missing functionality is summarized in the "Ownership Modes" charts in the form of red arrows.
4. boost allows implicit conversions between the lock types. N2406 made these conversions explicit. Rationale: changing the ownership mode of a mutex is something that should be well documented in the code.
I have an updated implementation of <shared_mutex> (under the boost license) here:
There is a tutorial-style description of this library here:
The tutorial includes a brief description of the use of most of the components, complete synopses, and an examples section. It also notes where this design differs from the boost design and explains why I believe the boost design is in error.
Comments appreciated, and all are welcome to use this code under the boost license. I will likely update this document in response to comments and its date at the top will correctly reflect the last time it was updated. This library, or a variation of it, will probably be submitted to TR2, and so getting feedback on the differences between this and the boost implementation is important.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk