|
|
Threads-Devel : |
From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-03-06 08:24:10
Matt Hurd wrote:
>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?
>
>
>
Wouldn't this break semantics? A condition generally is considered
a stateless thingy. So locking a condition clearly introduces state.
Besides this, what semantics could "locking a condition" posses?
I think I get the idea why you would suggest that, but this is a
technical issue, and I think this shouldn't leap into the interface.
(Still not sure if I understand you.)
>Too hasty:
>
>This breaks when you need more than one condition variable per mutex, though
>they should always refer to the same mutex.
>
>
This will also make it impossible to dynamically bind the condition
to different mutices.
At last you should also be able to use the mutex without a condition
at the same time, so hiding the mutex is not a good idea.
Your thoughts?