Boost logo

Boost :

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

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