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

This issue affects a number of other places, too. For example, the
documentation for scoped_lock states:

The type used to instantiate the class must meet the Mutex
requirements

However the Mutex requirements are clearly insufficient for the
scoped_lock template to work. Perhaps we could introduce (and
document!) a traits class for mutex operations?

Thanks,
D.P.