On Aug 21, 2007, at 3:06 PM, Roland Schwarz wrote:
Howard Hinnant wrote:
http://home.twcny.rr.com/hinnant/cpp_extensions/concurrency_rationale.html Thank you for your time and comments.
1) The document speaks about both: a) mutex with public lock unlock and b) moveable locks.
What does public lock unlock provide, that cannot be achieved with moveable locks also?
Mainly the ability to use user-defined locks with std-defined mutexes. And generalizing that statement: The ability for the client to write generic algorithms on mutexes. With the boost model if I want this freedom, I have to work only at the lock level, and not at the mutex level. Going up to the lock level adds inconvenience, and does not add safety. Examples include the mutex_debug mutex adaptor example in question 1. This can be written with the boost design but one has to include another data member, namely: Mutex::scoped_lock, in order to lock and unlock the mutex. In this example, nothing has been gained by eliminating the public member functions of the mutex. Indeed the debug adaptor now has a bigger sizeof. Alternatively you may want to write your own mutexes, and have them work with the std::supplied locks. This can't be done with the boost design, because there is no standard interface for your mutex to implement. An example user-written mutex might be: class my::mutex { public: mutex(); ~mutex(); void lock(); bool try_lock(); void unlock(); }; where my::~mutex() atomically locks itself and destructs. When my::mutex has static storage duration this means that any threads which owned a my::mutex at the same time static destructors are running, will block the static destruction until the thread releases the lock, thus (presumably) helping with an orderly shutdown. And when you get it all working, you can just as easily say std::unique_lock<my::mutex> lk(mut) (rather than reinventing your own lock class when that wasn't what you were interested in). This is much like our present day std::containers and std::algorithms. You can write your own container and have it work with all of the std::algorithms (as long as you follow the concepts). And you can write your own algorithm, and it will work with the std::containers (which meet your concepts). The public, standardized interface to mutexes is the link allowing this kind of interoperability between user-defined and std-defined mutexes and locks.
2) The example in Q2 uses a statically initialized mutex, but the reference implementation shows the mutex has a ctor. How is this supposed to be made thread-safe?
The current feeling on the committee is that function-local statics will initialize in a thread safe manner. This hasn't made it into the working paper yet, but I believe it soon will (perhaps as early as this October). -Howard