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.
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
