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.