Boost logo

Boost :

From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2007-08-20 19:08:57

On Aug 20, 2007, at 6:25 PM, Peter Dimov wrote:

> Howard Hinnant wrote:
>> Here is a link to a reference implementation and a FAQ for mutexes,
>> locks and condition variables I am currently anticipating proposing
>> for C++ standardization (or subsequent TR).
> I'm not particularly fond of the unchecked<> adaptor and the
> requirement
> that wait is called with the same mutex when the condition is
> default-constructed (stricter than POSIX). Why not make the latter the
> unchecked case? Before you answer "overhead", consider that wait
> blocks and
> is already a throwing function.

I realize that this is stricter than POSIX, however I'm not sure that
the difference in strictness has a practical consequence. We're
talking about a condition which would be waited on with mutex1 by a
group of threads, and then at some later date (synchronized properly
so as not to overlap) waited on with mutex2. Do you have motivating
use cases needing this functionality? Providing it gives up some
safety checks associated with the default constructor when code waits
on the same condition in more than one place (and can be error prone
when the locks are more than one type).

As far as overhead goes, I'm more concerned about space overhead than
performance overhead. On Mac, sizeof(pthread_cond_t) is 28, and
sizeof(pthread_mutex_t) is 44. I would really like for there to be be
an option for sizeof(std::condition) to be as close to 44 as
possible. Consider:

class MyClass
     std::tr2::upgrade_mutex mut_;

MyClass already has two std::condition's buried under the
upgrade_mutex (at least by my reference implementation). And MyClass
may be movable, or even copyable. That makes vector<MyClass> a very
real concern. And that makes space overhead very relevant. The
subsequent space overhead can lead to execution speed problems (not to
mention space problems on embedded systems).

Just like the std::algorithms, if people can't find a way to get the
best performance (both size and speed) out of the high level tools,
then there is always pressure to go down to the low level (C) tools.
I coded upgrade_mutex using the C level tools directly myself, was
really unhappy with the code, but it had the minimum space overhead.
It was that experience that led me to look for a high-level, minimum
space overhead solution. Perhaps condition<unchecked<mutex>> is the
wrong syntax. But I really think the solution has to be there in some
syntax. Else there is pressure on Joe Coder to drop down to
pthread_cond_t. And I liked the fact that I could change the type of
the condition from checked, to unchecked and back, without having to
change any other code associated with the condition.

I also considered unchecked::condition<mutex>,
unchecked_condition<mutex>, etc. But I liked the fact that
philosophically condition considered unchecked<mutex> just another
kind of mutex. That meant that client code could even by typedef'd on
unchecked<mutex> vs mutex for debug and release builds.
unchecked<Mutex> could just be a mutex adaptor class which does
nothing but alert code of the client's debug/release intent.


Boost list run by bdawes at, gregod at, cpdaniel at, john at