[boost] Swapability of named objects?

From: Daniel Spangenberg (dsp_at_[hidden])
Date: 2003-11-03 04:17:19

Hi boosters,

the current boost.thread library (My discussion concerns about
the official 1.30 version) provides the non-copyable property of
objects of mutex type. This is OK, but in the current development
of named synchronization objects for inter-process synchronization
the very question arises whether such an object should be
swappable or not. Consider a complex object

class MyClass
{
public:
  ...
  void swap(MyClass& other)
  {
    std::swap(internals_, other.internals_);
    std::swap(mutex_, other.mutex_); // Should we allow this?
    // Or least this: mutex_.swap(other.mutex_);
  }

private:
  ...
  T* internals_;
  mutable SomeMutex mutex_;
};

Under conditions of anonymous mutex objects (the current
contents of the thread library) the mutex object is a "gray"
black-box object, which does not have any properties
characterizing its host (an object of type MyClass) at the
moment of swapping - similar to the non-individuality of electrons;-).

But what about mutexes of the futural named_objects type?
Actually they have some individuality because they have a name
which makes same unique and thus identifiable and which
makes in addition different objects of the type MyClass
different from each other, such that it would make sense to
discuss whether this named objects should provide the
Swapable guarantee. This point of view can be visualized
by thinking of a possible member function name() in the class
MyClass.

What do you think concerning this question and probably
the question whether **any** objects which fits the Mutex
requirements should always provide the Swapable property?
(If I see that correct, the current implementations would
allow this).

This problem arose to me during the development of higher-order
synchronization objects (read-write-mutexes and the like) where
you can think of situations where such an object may **change**
its name during the lifetime of its host. To cope with this situation
we would at least need the swappable property to allow idioms
of that kind.

Greetings

Daniel