--- In boost@[...].. , davlet_panech <davlet_panech@[...]..>  wrote:
>  --- In boost@[...].. , bill_kempf <williamkempf@[...]..> wrote:
>  > --- In boost@[...].. , davlet_panech <davlet_panech@[...]..> 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.