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.