Boost logo

Boost :

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
> > 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
> > am mistaken, doesn't mention anything named `m_mutex'. Am I
> > something here?
> Not exactly. The m_mutex parameter is a private parameter, and
> not part of the concept requirements. It's an implementation
> requirement. If an implementation for a given platform can be
> with out this requirement there's nothing wrong with that.
> However, I can see problems with someone trying to extend the
> 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


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?

Boost list run by bdawes at, gregod at, cpdaniel at, john at