[boost] Idiot-proof mutex [was: RFC standard proposed mutex, read-write mutex, condition]

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-08-24 09:57:38

Dear All,

I have been a humble user of Boost.Thread for some time and have found 
it very satisfactory.  I have tried to follow this thread and I believe 
that I understand the reasons for the extra features that Howard's 
proposal adds, but I worry that in doing so it becomes easier to shoot 
oneself in the foot, and in some cases the code becomes more verbose.  
Specifically I'm thinking of the public lock() and unlock() methods.

I'm not suggesting that for this reason we should remove features from 
the proposal.  Instead, I'd like to suggest that we consider a 
std::idiot_proof_mutex|condition or boost::idiot_proof_mutex|condition 
offering a safer, simpler interface, implemented on top of the  
full-features primitives that Howard proposes.  I imagine that this 
would be zero-overhead.  Any thoughts?

In the same vein, I have sometimes considered making the use of these 
primitives even more idiot-proof by bundling together a mutex, 
condition and the variable that they protect:

template <typename T>
class locked {
   mutex m;
   condition c;
   T v;
};

and then adding code so that the variable v can only be accessed when 
an appropriate lock is held.  I.e.:

typedef locked< vector<int> > x_t;
x_t x;

// Change x:
{
   x_t::writer xw;   // constructor creates a write-lock on the mutex
                     // is convertible to a reference to vector<int>
   xw.push_back(123);
   xw.push_back(321);
}                   // destructor destroys the write-lock and notifies 
the condition

// Access x:
{
   x_t::reader xr;  // constructor takes a read-lock on the mutex
                    // is convertible to a const reference to vector<int>
   while (xr.empty()) {
     xr.wait();     // wait on the condition
   }
   cout << xr[0];
}                  // destructor destroys the read-lock

Is this do-able?  Has it already been done?  (I have a vague feeling 
that maybe Java has something like this, but I could be wrong.)

Regards,

Phil.