Re: [boost] Boost.Threads, N2178, N2184, et al

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-03-22 18:08:32

Howard Hinnant wrote:
> On Mar 22, 2007, at 3:20 PM, Yuval Ronen wrote:
> 
>> The main thing I was thinking about is the move constructor. Instead  
>> of
>> stealing the mutex from the rvalue, you construct a new mutex, and let
>> the old one be destructed. This might be not optimal. But on the other
>> hand, it might not be that bad after all, I don't know...
> 
> <nod> If it did turn up a red flag in the profiling of A, then perhaps  
> A could be changed to:
> 
> class A
> {
>      int* the_data_;
>      std::unique_ptr<std::sharable_mutex> mut_;
>      ...
> 
> With an invariant that if the_data_ is non-null then so is mut_,  
> otherwise both are null.
> 
> This would probably (I haven't fully analyzed it) be no more  
> inefficient than if we did this:
> 
> class mutex
> {
>      pthread_mutex_t* mut_; // on heap
>      ...
> 
> And it enables other clients of mutex to not have to pay for a heap  
> allocation internal to std::mutex if their app didn't need it.

I agree.

> Hmm... and if your std::mutex ctor can throw an exception (in general  
> it can), the A design with a plain mutex has a throwing move  
> constructor which can be bad if you want to vector<A>.  The A design  
> with the mutex* side steps that problem I believe.

So the general recommendation for a class that holds a mutex and should 
be movable is to dynamically allocate the mutex. Pity, but maybe inevitable.

<fantasy> Unless POSIX would change to allow movable pthread_mutex_t... 
</fantasy>