Re: mutex_traits<>

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-31 10:29:44

--- In boost_at_y..., Jeremy Siek <jsiek_at_c...> wrote:
> On Thu, 31 Jan 2002, bill_kempf wrote:
> willia>
> willia> OK, in this particular case I'd be open to that.  If 
nothing else it
> willia> eliminates the concern for not supporting all operations of 
the
> willia> traits class.  However, this isn't the "typical" solution 
in C++
> willia> design that I've seen, and as free functions the above 
operations
> willia> appear to be more open to misuse.  In otherwords, 
a "newbie" is
> willia> likely to see:
> willia>
> willia> template <typename Mutex>
> willia> void lock(Mutex& m);
> 
> By free function I didn't mean function template, I was thinking 
lock()
> functions overloaded on the particular mutex types.

Results in the same thing, though it actually makes the 
implementation more difficult.  With the current Boost.Threads 
implementation the template can be written to cover all mutex 
variants, and user defined mutex types (that shouldn't know about the 
implementation details) can specialize the template for their types.

> willia> and use it then he is if it's wrapped in a traits class.  
If that's
> willia> the case, why not just expose these methods as public 
methods in the
> willia> Mutex?
> 
> Good question, why not? Perhaps you should post your design goals 
for this
> component. I can guess at them... but I might be wrong and so might 
be
> others.

Making lock() operations easily accessible is likely to lead to 
newbie mistakes.  Not exposing them at all makes it 
difficult/impossible to extend the library, such as with a lock_ptr<> 
concept.

A trickier issue is that the variants that take the cv_traits 
references are implementation details used to allow the mutexes to 
work with boost::condition.  The more I think about these the more I 
don't know what the solution is.  Just exposing the methods won't 
help anyone, since what they have to do is platform specific.  I'm 
not at all sure there's a way to refactor it in order to remove this 
fact, and so there may be no purpose in exposing the methods at all, 
but that means the library can't be portably extended with custom 
mutex types that will work with boost::condition.

Bill Kempf