Hi Phil, ----- Original Message ----- From: "Phil Endecott" <spam_from_boost_dev@chezphil.org> To: <boost@lists.boost.org> Sent: Friday, May 09, 2008 3:05 PM Subject: Re: [boost] [thread] is this reverse_lock class a source of errors?
vicente.botet wrote:
{ unique_lock<mutex> lock(smtx);
// ... some writing operations
{ // non locked block reverse_lock< unique_lock<mutex> > rlock(lock); // ... some code not needing the mutex to be locked } // locked again
// ... }
I wrote something like this to use inside my condition variable implementation and called it "unlock". I think I prefer the name "unlock" to "reverse_lock", personally. In my case I have only a subset of the proposed C++0x mutex and lock functionality, making the implementation simpler and the potential for errors low.
template <typename MUTEX_T> struct Unlock: boost::noncopyable {
typedef MUTEX_T mutex_t;
mutex_t& m;
explicit Unlock(mutex_t& m_): m(m_) { m.unlock(); }
~Unlock() { m.lock(); }
mutex_t* mutex(void) { return &m; } };
Thanks for the explict contructor and the boost::noncopyable. I have started implementing it like you, but the interaction with the nesting locks is not so clean (nesting_lock has ownership on mtx (1) which is not correct). Of course this class is clean if there is not a nesting lock and much more efficient. { unique_lock<mutex> nesting_lock(mtx); // ... some writing operations { // non locked block reverse_lock< mutex > rlock(mtx); // (1) // ... some code not needing the mutex to be locked } // locked again // ... } We can use the Operator Traits/Concept Traits library (Not yet submitet to Boost) and enable_if to create two partial specialization and have both classes with the same name. I'm not sure that preserve the name is important, but I can, if nobody has already do it, define the BCCL Lockable Concepts and its concept traits counterparts. Currently there are no concepts for the Boost.Thread locks, which seams quite natural because there is neither a class nor a function which takes a Lock as template parameter (except condition_variable_any::wait). Has someone already defined the locks concepts?
Once you have recursive mutexes, shared locks and the other features, the possible interactions start to get interesting.
The interaction with shared_lock seams to be OK. I don't see any problems with recursive_mutex. Could you show, if you have already identified, which interactions can be an issue?
I have wondered whether a subset of the C++0x features, closer to the old Boost.Threads API, could be useful as a "threads-for-beginners" package.
Could you be more precise, to which subset are you referring? Best Vicente