Boost logo

Boost :

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-09 13:16:15

Hi Phil,

----- Original Message -----
From: "Phil Endecott" <spam_from_boost_dev_at_[hidden]>
To: <boost_at_[hidden]>
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?



Boost list run by bdawes at, gregod at, cpdaniel at, john at