Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-31 16:00:43

--- In boost_at_y..., Jeremy Siek <jsiek_at_c...> wrote:
> On Thu, 31 Jan 2002, bill_kempf wrote:
> willia>
> willia> I've already done that much. The lock.hpp file defines a
> willia> class that does precisely this, though it's in detail land
instead of
> willia> exposed in the public interface.
> lock_ops is a little different. Here's what I'm thinking the usage
> would look like:
> mutex m;
> ...
> mutex_access_private(m).lock()
> where mutex_access_private() is a helper function that creates the
> wrapper:
> template <class Mutex>
> class mutex_private_accessor {
> public:
> mutex_private_accessor(Mutex& m) : m_mtx(m) { }
> void lock() { m_mtx.lock(); }
> ...
> private:
> Mutex& m_mtx;
> };
> template <class Mutex>
> mutex_private_accessor<Mutex> mutex_access_private(Mutex& m)
> {
> return mutex_private_accessor<Mutex>(m);
> }

The only difference between this and lock_ops is that lock_ops uses
static methods, so there's not a lot of real difference here. The
function that returns this proxy is an interesting idea, though. The
final syntax isn't much of an improvement, though:




The only benefit is that you no longer have to specify the type.

The same thing could be done by making lock_ops a non-template class
with template members, though:


> willia> The real issue here is actually how to interact with
> willia> boost::condition, however. I can't quite see how to
document this
> willia> well enough in the public interface to allow for mutex
> willia> that work with the condition variable.
> Hmm, I'd have to understand the problem better...

The boost::condition::wait() (and timed_wait()) operations make use
of private lock/unlock methods in the mutexes that take a cv_state
reference. The cv_state is a nested type that's platform specific.
On the Windows platform it holds state information such as the number
of nested locks for a recursive_mutex. The POSIX stuff holds this
state information as well as a pointer to the pthread_mutex instance
that's used in the call to pthread_cond_wait(). So the state
information is mostly specific to the mutex type, but also requires
certain information on some platforms regardless of the mutex type.
Simply leaving it as is (i.e. an implementation detail) prevents
users from creating new mutex types, such as a named_mutex, which can
be used with boost::condition. But I don't know how to modify this
design so that platform specific information isn't exposed to the

Bill Kempf

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