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; } }; Once you have recursive mutexes, shared locks and the other features, the possible interactions start to get interesting. 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. Phil.