Re: [boost] boost::thread and move semantics

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-12-18 11:48:16

On Dec 18, 2007, at 3:47 AM, Anthony Williams wrote:

> Frank Mori Hess <frank.hess <at> nist.gov> writes:
>
>> On Monday 17 December 2007 09:59 am, Anthony Williams wrote:
>>>
>>> I have removed detail::thread_move(). Instead, I've added  
>>> boost::move
>>> overloads for the movable types in boost.thread: thread,  
>>> unique_lock<>,
>>> shared_lock<>, upgrade_lock<>. Since these overloads take specific
>>> parameter types, they shouldn't cause the problems that the  
>>> unconstrained
>>> template caused before.
>>
>> Have you considered making the mutex types movable?  I'm working on  
>> some mutex
>> wrapper classes and it would be nice to be able to move construct  
>> the wrapper
>> from an object of its templated mutex type, instead of assuming the  
>> mutex
>> type is going to be default constructible.
>
> On POSIX, mutex types are not movable. Making boost::mutex movable  
> would mean
> that either we could not use pthread_mutex_t internally, or we would  
> have to
> dynamically allocate it. I don't think it makes sense to restrict the
> implementation in that way.

Having one thread move a mutex while another thread has it locked  
could be a scary thing.

That being said, a non-movable boost::mutex does not prohibit a  
wrapper around that type from being movable, if you're willing to  
accept alternative semantics.  I'm not familiar with the boost move  
library, but the C++0X syntax would simply be:

class my_wrapper
{
     std::mutex mut_;  // or boost::mutex
public:
     my_wrapper() {}
     my_wrapper(my_wrapper&&) {}  // same as default ctor
     my_wrapper& operator=(my_wrapper&&) {return *this;}  // do nothing

     void lock() {mut_.lock();}
     bool try_lock() {return mut_.try_lock();}
     void unlock() {mut_.unlock();}
};

-Howard