Re: mutex_traits<>

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-31 09:53:23

--- In boost_at_y..., Jeremy Siek <jsiek_at_c...> wrote:
> On Wed, 30 Jan 2002, bill_kempf wrote:
> > OK, we've discovered the need to move some things I'd considered
> > implementation details into some form of public interface.  My
> > thinking is to define some traits classes that allow these 
details to
> > be specified.  The first "draft" of a mutex_traits<> type looks 
like
> > this:
> >
> > template <typename Mutex>
> > class mutex_traits
> > {
> > public:
> >     typedef <i>Implementation Defined</i> cv_state;
> >     static void lock(Mutex& mutex);
> >     static void trylock(Mutex& mutex);
> >     static void timedlock(Mutex& mutex);
> >     static void unlock(Mutex& mutex);
> >     static void lock(Mutex& mutex, cv_state& state);
> >     static void unlock(Mutex& mutex, const cv_state& state);
> > };
> 
> I prefer free functions to static-functions-in-a-traits-class.

OK, in this particular case I'd be open to that.  If nothing else it 
eliminates the concern for not supporting all operations of the 
traits class.  However, this isn't the "typical" solution in C++ 
design that I've seen, and as free functions the above operations 
appear to be more open to misuse.  In otherwords, a "newbie" is 
likely to see:

template <typename Mutex>
void lock(Mutex& m);

and use it then he is if it's wrapped in a traits class.  If that's 
the case, why not just expose these methods as public methods in the 
Mutex?

> > >From a design standpoint, is it OK to use this with types such as
> > boost::mutex which don't support all the methods, or do we need
> > seperate traits classes for try and timed mutex variants?  The
> > compiler will catch misuses when using a single traits template, 
but
> > I'm still not sure that it's "proper" to design this with a single
> > traits type.
> 
> You won't have these problems with a free function approach.
> 
> Beware the monolithic interface!
> 
> > The other issue is that the above definition won't map to a
> > read_write_mutex which doesn't have a lock() operation but instead
> > has a read_lock() and a write_lock() operation.  I'm not sure how 
to
> > deal with this, or if I actually should deal with it.
> >
> > Comments/ideas?
> 
> If two operations have different semantics, then they should have
> different names. If two operations have the same semantics, then we 
can do
> generic programming, and they should have the same name.

I agree.  But the semantic differences aren't great enough to 
automatically eliminate the read_write_mutex from use with a 
condition variable.  I can think of a few ways around this, I just 
wanted to know if anyone else had ideas.
 
Bill Kempf