Re: Boost.Threads: concept requirements

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-30 14:13:57

--- In boost_at_y..., "davlet_panech" <davlet_panech_at_y...> wrote:
> --- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> > --- In boost_at_y..., "davlet_panech" <davlet_panech_at_y...> wrote:
> > > Hi,
> > > 
> > > It seems that the current implementation of some Boost.Threads 
> > > classes violates it's concept requirements, for example, here's 
> how 
> > > condition::wait() looks like:
> > > 
> > >     template <typename L>
> > >     void wait(L& lock)
> > >     {
> > >         if (!lock)
> > >             throw lock_error();
> > > 
> > >         do_wait(lock.m_mutex);
> > >     }
> > > 
> > > 
> > > Type L is supposed to implement ScopedLock concept, which, 
unless 
> I 
> > > am mistaken, doesn't mention anything named `m_mutex'. Am I 
> missing 
> > > something here?
> > 
> > Not exactly.  The m_mutex parameter is a private parameter, and 
> thus 
> > not part of the concept requirements.  It's an implementation 
> detail 
> > requirement.  If an implementation for a given platform can be 
> coded 
> > with out this requirement there's nothing wrong with that.
> > 
> > However, I can see problems with someone trying to extend the 
> library 
> > with their own Mutex and ScopedLock variants that they want to 
work 
> > with boost::condition, and this sort of implementation detail 
> > prevents this.  So, there may be a small flaw in the design.
> > 
> > Anyone have any ideas about whether we should do something about 
> > this, and if so, what?
> > 
> > Bill Kempf
> 
> Bill,
> 
> Here is another thing: it seems that the only class that can be 
used 
> to instantiate boost::scoped_lock is boost::mutex, since 
> boost::scoped_lock uses (undocumented) "implementation details" of 
> its template parameter. So why is scoped_lock a template then? I 
> think we should either promote those implementation details to 
> concept requirements, or make scoped_lock non-parametrized, say:

There is no boost::scoped_lock.  There's a boost::detail::scoped_lock 
that's a template helper used for defining the various 
Mutex::scoped_lock types.  This is all an implementation detail, and 
foo::some_mutex::scoped_lock is not required to be implemented using 
boost::detail::scoped_lock.  That's not going to change.  However, to 
allow foo::some_mutex::scoped_lock to work with boost::condition I 
will have to modify the ScopedLock concept to allow for access to the 
mutex, in addition to defining a mutex_traits<> that will give access 
to the various lock functions.

> I can think of similar considerations for the condition class. I 
just 
> have a problem with all these classes being separately 
parametrized, 
> yet the dependancies between these parameters are not reflected in 
> the design -- once you change the parameter of scoped_lock to 
> anything other than mutex, the condition class becomes unusable.
> 
> What do you think?

I've got a general idea about how to go about exposing these details 
in formalized concepts.  There are some things I'm concerned with, 
however.  For instance, a read_write_mutex exposes a different set of 
lock operations then normal Mutexes.  It will be clumsy trying to 
force the obvious mutex_traits<> definition onto this type, though I 
can imagine it might be useful to use such a mutex with a condition.  
One solution would be to expose not only a mutex_traits<> but also a 
lock_traits<>, which would allow the read_write_mutex to have a 
scoped_read_lock and a scoped_write_lock that could be used with 
boost::condition.  This means that mutex_traits<> still must define 
some sort of "useful" behavior... maybe defining the lock operations 
in terms of write locks only?

Bill Kempf
> D.P.