Boost logo

Boost :

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>> 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
     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();}


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