Re: [boost] [thread] RFC standard proposed mutex, read-write mutex, condition

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).
>>
>> http://home.twcny.rr.com/hinnant/cpp_extensions/concurrency_rationale.html
>
> 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.

-Howard