Re: mutex_traits<>

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 
lock_ops
> 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 
syntax
> 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:

mutex_private_accessor(mutex).lock();

vs.

lock_ops<boost::mutex>::lock(mutex);

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:

lock_ops::lock(mutex);

> 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 
extensions
> 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 
user.

Bill Kempf