Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-22 16:05:39


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.

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.

-Howard


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk