Невозможно скомпилировать вектор & lt; queue & lt; t & lt; T1, T2 & gt; & gt; & gt; & gt; [Дубликат]

Прежде всего, в вашем дизайне должно быть что-то не так, если вы хотите переместить объект, содержащий мьютекс.

Но если вы все равно решите это сделать, вам нужно создать новый мьютекс в конструкторе перемещения, например:

// movable
struct B{};

class A {
    B b;
    std::mutex m;
public:
    A(A&& a)
        : b(std::move(a.b))
        // m is default-initialized.
    {
    }
};

Это поточно-безопасное, потому что движение конструктор может с уверенностью предположить, что его аргумент нигде не используется, поэтому блокировка аргумента не требуется.

Учитывая, там, кажется, не быть хороший, чистый, простой способ ответить на этот - решение Антона I думать является правильным, но его определенно спорно, если лучший ответ не приходит, я бы рекомендовал положить такой класс в куче и ухаживать за ним через std::unique_ptr:

auto a = std::make_unique<A>();

Теперь он полностью перемещаемый, и любой, у кого есть блокировка внутреннего мьютекса, в то время как происходит движение, по-прежнему безопасен, даже если его обсуждать, хорошо ли это делать

. Если вам нужна семантика копирования, просто используйте

auto a2 = std::make_shared<A>();

Использование мьютексов и семантики перемещения C ++ - отличный способ безопасно и эффективно передавать данные между потоками.

Представьте себе поток «производителя», который производит партии строк и предоставляет их (одному или нескольким) потребителям , Эти партии могут быть представлены объектом, содержащим (потенциально большие) std::vector<std::string> объекты. Мы абсолютно хотим «переместить» внутреннее состояние этих векторов в своих потребителей без ненужного дублирования.

Вы просто признаете мьютекс как часть объекта, не являющегося частью состояния объекта. То есть, вы не хотите перемещать мьютексы.

Какая блокировка вам нужна, зависит от вашего алгоритма или от того, насколько обобщены ваши объекты и какой диапазон использования вы разрешаете.

Если вы только когда-либо переходите от объекта «продюсер» общего состояния к локальному «потребляющему» объекту потока, у вас может быть достаточно, чтобы заблокировать перемещение с объекта.

Если это более общий дизайн, вам нужно будет заблокируйте оба. В этом случае вам нужно подумать о блокировке блокировки.

Если это потенциальная проблема, используйте std::lock() для получения блокировок на обоих мьютексах без блокировки.

http://en.cppreference.com/w/cpp/thread/lock

В качестве последней заметки вам нужно убедиться, что вы понимаете семантику перемещения. Напомним, что перемещенный из объекта остается в действительном, но неизвестном состоянии. Вполне возможно, что поток, не выполняющий перемещение, имеет вескую причину для попытки доступа к перемещенному объекту, когда он может найти это действительное, но неизвестное состояние.

Опять мой продюсер просто выбивает строки, а потребитель отнимая всю нагрузку. В этом случае каждый раз, когда производитель пытается добавить к вектору, он может найти вектор непустым или пустым.

Короче, если потенциальный одновременный доступ к перемещенному объекту составляет запись, это, вероятно, будет ОК. Если это будет прочитано, подумайте, почему нормально читать произвольное состояние.

Это перевернутый ответ. Вместо того, чтобы встраивать «эти объекты нужно синхронизировать» в качестве базы этого типа, вместо этого вставляйте под любым типом.

Вы имеете дело с синхронизированным объектом по-разному. Одна из серьезных проблем - вы должны беспокоиться о взаимоблокировках (блокировка нескольких объектов). Это также никогда не должно быть вашей «стандартной версией объекта»: синхронизированные объекты предназначены для объектов, которые будут в конфликте, и ваша цель должна заключаться в том, чтобы свести к минимуму конфликт между потоками, а не подметать его под ковер.

Но синхронизация объектов по-прежнему полезна. Вместо наследования от синхронизатора мы можем написать класс, который обертывает произвольный тип при синхронизации. Пользователи должны перейти через несколько обручей, чтобы выполнять операции над объектом теперь, когда они синхронизированы, но они не ограничены каким-то ограниченным набором операций с ограниченным ручным управлением для объекта. Они могут составлять несколько операций над объектом в один или работать с несколькими объектами.

Вот синхронизированная обертка вокруг произвольного типа T:

template<class T>
struct synchronized {
  template<class F>
  auto read(F&& f) const&->std::result_of_t<F(T const&)> {
    return access(std::forward<F>(f), *this);
  }
  template<class F>
  auto read(F&& f) &&->std::result_of_t<F(T&&)> {
    return access(std::forward<F>(f), std::move(*this));
  }
  template<class F>
  auto write(F&& f)->std::result_of_t<F(T&)> {
    return access(std::forward<F>(f), *this);
  }
  // uses `const` ness of Syncs to determine access:
  template<class F, class... Syncs>
  friend auto access( F&& f, Syncs&&... syncs )->
  std::result_of_t< F(decltype(std::forward<Syncs>(syncs).t)...) >
  {
    return access2( std::index_sequence_for<Syncs...>{}, std::forward<F>(f), std::forward<Syncs>(syncs)... );
  };
  synchronized(synchronized const& o):t(o.read([](T const&o){return o;})){}
  synchronized(synchronized && o):t(std::move(o).read([](T&&o){return std::move(o);})){}  
  // special member functions:
  synchronized( T & o ):t(o) {}
  synchronized( T const& o ):t(o) {}
  synchronized( T && o ):t(std::move(o)) {}
  synchronized( T const&& o ):t(std::move(o)) {}
  synchronized& operator=(T const& o) {
    write([&](T& t){
      t=o;
    });
    return *this;
  }
  synchronized& operator=(T && o) {
    write([&](T& t){
      t=std::move(o);
    });
    return *this;
  }
private:
  template<class X, class S>
  static auto smart_lock(S const& s) {
    return std::shared_lock< std::shared_timed_mutex >(s.m, X{});
  }
  template<class X, class S>
  static auto smart_lock(S& s) {
    return std::unique_lock< std::shared_timed_mutex >(s.m, X{});
  }
  template<class L>
  static void lock(L& lockable) {
      lockable.lock();
  }
  template<class...Ls>
  static void lock(Ls&... lockable) {
      std::lock( lockable... );
  }
  template<size_t...Is, class F, class...Syncs>
  friend auto access2( std::index_sequence<Is...>, F&&f, Syncs&&...syncs)->
  std::result_of_t< F(decltype(std::forward<Syncs>(syncs).t)...) >
  {
    auto locks = std::make_tuple( smart_lock<std::defer_lock_t>(syncs)... );
    lock( std::get<Is>(locks)... );
    return std::forward<F>(f)(std::forward<Syncs>(syncs).t ...);
  }

  mutable std::shared_timed_mutex m;
  T t;
};
template<class T>
synchronized< T > sync( T&& t ) {
  return {std::forward<T>(t)};
}

C ++ 14 и C ++ 1z.

это предполагает, что операции const являются безопасными с несколькими считывателями (что предполагает контейнер std).

Использовать внешний вид например:

synchronized<int> x = 7;
x.read([&](auto&& v){
  std::cout << v << '\n';
});

для int с синхронизированным доступом.

Я бы посоветовал не иметь synchronized(synchronized const&). Это редко бывает необходимо.

Если вам нужно synchronized(synchronized const&), у меня возникнет соблазн заменить T t; на std::aligned_storage, разрешить конструкцию ручного размещения и ручное уничтожение. Это позволяет правильное управление жизненным циклом.

Если это не удалось, мы могли бы скопировать источник T, а затем прочитать из него:

synchronized(synchronized const& o):
  t(o.read(
    [](T const&o){return o;})
  )
{}
synchronized(synchronized && o):
  t(std::move(o).read(
    [](T&&o){return std::move(o);})
  )
{}

для назначения:

synchronized& operator=(synchronized const& o) {
  access([](T& lhs, T const& rhs){
    lhs = rhs;
  }, *this, o);
  return *this;
}
synchronized& operator=(synchronized && o) {
  access([](T& lhs, T&& rhs){
    lhs = std::move(rhs);
  }, *this, std::move(o));
  return *this;
}
friend void swap(synchronized& lhs, synchronized& rhs) {
  access([](T& lhs, T& rhs){
    using std::swap;
    swap(lhs, rhs);
  }, *this, o);
}

размещение и выровненные версии хранилищ немного беспорядочны. В большинстве случаев доступ к t будет заменен на функцию-член T&t() и T const&t()const, за исключением конструкции, где вам придется перепрыгивать через некоторые обручи.

Сделав synchronized вместо обертки части класса, все, что мы должны убедиться, состоит в том, что класс внутренне уважает const как многократный читатель и записывает его однопоточным способом.

В редких случаях нам нужно синхронизированный экземпляр, мы прыгаем через обручи, как показано выше.

Извините за любые опечатки в приведенном выше. Вероятно, есть некоторые.

. Преимущество вышеизложенного заключается в том, что n-арные произвольные операции над объектами synchronized (одного и того же типа) работают вместе, без необходимости жестко кодировать их перед началом работы. Добавить в объявление друга и n-ary synchronized объекты нескольких типов могут работать вместе. Мне может потребоваться переместить access из встроенного друга, чтобы иметь дело с перегрузками в этом случае.

live example