Re: Boost.Threads: concept requirements

From: davlet_panech (davlet_panech_at_[hidden])
Date: 2002-01-30 13:50:37

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

class scoped_lock
{
  class mutex; // unspecified
  ...
};

Here, the scoped_lock::mutex type is required to be constructible, 
but may contain additional, unspecified members, which scoped_lock 
makes use of. The syntax would then be:

boost::scoped_lock::mutex m;

void foo()
{
  boost::scoped_lock lk( m );
  ...
}

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?
D.P.