[thread] shared_mutex replaces read_write_mutex?
Hi, will shared_mutex replace read_write_mutex? Where can I reasd more about the usage of shared_mutex (http://svn.boost.org/svn/boost/trunk/libs/thread/doc/ doesn't contain an explanation)? best regards, Oliver
Kowalke Oliver (QD IT PA AS <Oliver.Kowalke <at> qimonda.com> writes:
will shared_mutex replace read_write_mutex?
Yes.
Where can I reasd more about the usage of shared_mutex (http://svn.boost.org/svn/boost/trunk/libs/thread/doc/ doesn't contain an explanation)?
It will be in the new docs when I get them finished. In the meantime, you can read Howard's papers presented to the C++ Standards committee: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2094.html --- original proposal featuring shared_mutex http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html --- rational which includes shared_mutex discussion. Note that boost::shared_mutex currently includes the upgrade_mutex behaviour. Basically unique_lock<shared_mutex> will give you a write lock, shared_lock<shared_mutex> will give you a read lock, and upgrade_mutex<shared_mutex> will give you a read lock than you can upgrade by transferring ownership (with move) to a unique_lock<shared_mutex>. Anthony
Hi, nice that the read-/write-mutex facility will be available with boost-1.35! I looked into the code and I've a question: in the shared_mutex.hpp the default-ctor of shared_mutex does initialize in the ctor body instead using the initialisation list. Could you explain me why this way was choosen? (if I can remember correctly - Scott Meyers voted for using initialisation lists over assignment in ctors). best regards, Oliver
will shared_mutex replace read_write_mutex?
Yes.
Where can I reasd more about the usage of shared_mutex (http://svn.boost.org/svn/boost/trunk/libs/thread/doc/ doesn't contain an explanation)?
It will be in the new docs when I get them finished. In the meantime, you can read Howard's papers presented to the C++ Standards committee:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2094. html --- original proposal featuring shared_mutex http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406. html --- rational which includes shared_mutex discussion.
Note that boost::shared_mutex currently includes the upgrade_mutex behaviour.
Basically unique_lock<shared_mutex> will give you a write lock, shared_lock<shared_mutex> will give you a read lock, and upgrade_mutex<shared_mutex> will give you a read lock than you can upgrade by transferring ownership (with move) to a unique_lock<shared_mutex>.
Anthony
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I looked into the code and I've a question: in the shared_mutex.hpp the default-ctor of shared_mutex does initialize in
Kowalke Oliver (QD IT PA AS <Oliver.Kowalke <at> qimonda.com> writes: the ctor body instead using
the initialisation list. Could you explain me why this way was choosen? (if I can remember correctly - Scott Meyers voted for using initialisation lists over assignment in ctors).
The POSIX code is based on the win32, which does the initialization in the constructor body. There is probably not a sensible reason in this case. For win32, the semaphores are stored in an array (for use with WaitForMultipleObjects), and arrays can't be initialized in the constructor initialization list. It then made sense to initialize everything in the body, so it was done in one place. Anthony
participants (2)
-
Anthony Williams -
Kowalke Oliver (QD IT PA AS)