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

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-03-22 13:14:46

Howard Hinnant wrote:
> On Mar 21, 2007, at 5:20 PM, Yuval Ronen wrote:
> 
>> Makes a lot of sense. Makes me wonder why the mutexes in N2094 are not
>> movable also.
> 
> I actually thought about that.  My inclination is to model pthreads  
> (which also appears to have been the boost inclination).  And  
> pthread_mutex_t does not appear to be a copyable item.

Copyable - no, but is it movable?

> And I'm wanting to be able to implement like this:
> 
> class mutex
> {
>      pthread_mutex_t mut_;
> public:
>      ...
> };
> 
> as opposed to:
> 
> class mutex
> {
>      pthread_mutex_t* mut_;  // on heap
> public:
>      ...
> };

Perfectly understood.

> It appears that a pthread implementation is allowed to point into a  
> pthread_mutex_t and thus copy/moving it becomes problematic.

So according to this, it seems that pthread_mutex_t isn't moveable. 
That's a problem.

> To alleviate this, N2094 does make the locks movable.  The locks  
> simply have a pointer to the mutex.  The pointer controls (owns) the  
> locked status of the mutex, not the lifetime of it though.

Yes, of course.

> The usual  
> idiom is to have the mutex at namespace scope, or as a class data  
> member, and have the lock referring to that mutex "on the stack".  So  
> for the usual idioms, non-copyable, non-movable mutexes do not seem  
> overly problematic.

I'm not sure it's not problematic. If the mutex is class data member (a 
very common scenario - perhaps the most common one), then it makes that 
class non-movable. Non-copyable - I understand, but non-movable - that's 
a major limitation, IMO.

> In contrast, pthread_t is clearly copyable.
> 
>      pthread_t pthread_self();
> 
> However the semantics of pthread_t when looked at through a C++ lens  
> is: sole ownership.
> 
> *  A pthread_t initialized from pthread_create, must be joined or  
> detached exactly once.

No argument between us here...