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...