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

Hmm??

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_)
  ....
private:
  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...??

matt.


Threads-Devel list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk