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