Boost logo

Threads-Devel :

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2006-03-06 06:17:53

On Monday 06 March 2006 22:00, Matt Hurd wrote:
> On Monday 06 March 2006 22:02, Roland Schwarz wrote:
> > Matt Hurd wrote:
> > >To avoid the errors in writing portable code I discussed before. Making
> > > a recursive mutex the default makes a large class of portability errors
> > > go away.
> >
> > Sorry, I disagree. Windows does not have the concept of condition
> > variables, but pthreads has. Recursive mutex behaviour is potentially
> > dangerous when used with a condition variable. So this might explain
> > why windows has recursive per default.
> > And if you are using recursive mutex together with condition variables
> > you can detected inappropriate usage only during runtime.
> Not if you take my later suggestion of requiring the mutex type to be
> embedded within the condition var as there is usually only a specific mutex
> that will work with the condvar.
> e.g.
> boost::condition::mutex
> This prevents the problem of using the wrong mutex type.
> Your thoughts?
> matt.

A further $0.02.

Apologies for replying to my own mail.

Perhaps a boost::condition is just that and _includes_ an embedded mutex of
the appropriate type. This would suit my normal practice though I'm not sure
if it makes sense everywhere??

  void do()
    lock lk(guard_.mutex());

  boost::condition guard_;


If so then perhaps a boost::condition is simply a lockable thing without
explicitly exposing the mutex?

Too hasty:

This breaks when you need more than one condition variable per mutex, though
they should always refer to the same mutex.

It is still a good idea I think, but you could create a secondary condvar from
the first and thus re-use its mutex.

   : guard_(), guard_empty_(guard_)
  boost::condition guard_empty

Or perhaps just enable a condition to be created w.r.t. a mutex, default is to
create an internal one but then you may initialise with a different
condition's mutex or any reference to a mutex...??


Threads-Devel list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at