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