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

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.