Почнемо з трохи коду:
class A
{
using MutexType = std::mutex;
using ReadLock = std::unique_lock<MutexType>;
using WriteLock = std::unique_lock<MutexType>;
mutable MutexType mut_;
std::string field1_;
std::string field2_;
public:
...
Я вклав туди кілька сугестивних псевдонімів типу, якими ми не зможемо скористатися в C ++ 11, але стаємо набагато кориснішими в C ++ 14. Наберіться терпіння, ми доїдемо.
Ваше запитання зводиться до:
Як написати конструктор переміщення та оператор присвоєння переміщення для цього класу?
Ми почнемо з конструктора переміщення.
Конструктор переміщення
Зверніть увагу, що учасник mutexбув зроблений mutable. Строго кажучи, це не обов’язково для учасників переміщення, але я припускаю, що ви також хочете скопіювати членів. Якщо це не так, немає потреби робити мутекс mutable.
При будівництві Aвам не потрібно блокувати this->mut_. Але вам потрібно заблокувати mut_об’єкт, з якого ви будуєте (перемістити або скопіювати). Це можна зробити так:
A(A&& a)
{
WriteLock rhs_lk(a.mut_);
field1_ = std::move(a.field1_);
field2_ = std::move(a.field2_);
}
Зверніть увагу, що ми повинні були за замовчуванням побудувати члени thisfirst, а потім присвоювати їм значення лише після того, a.mut_як блокується.
Переміщення призначення
Оператор присвоєння переміщення істотно складніший, оскільки ви не знаєте, чи має якийсь інший потік доступ до lhs або rhs виразу присвоєння. І взагалі, потрібно захищатися від наступного сценарію:
x = std::move(y);
y = std::move(x);
Ось оператор призначення переміщення, який правильно захищає наведений вище сценарій:
A& operator=(A&& a)
{
if (this != &a)
{
WriteLock lhs_lk(mut_, std::defer_lock);
WriteLock rhs_lk(a.mut_, std::defer_lock);
std::lock(lhs_lk, rhs_lk);
field1_ = std::move(a.field1_);
field2_ = std::move(a.field2_);
}
return *this;
}
Зверніть увагу, що std::lock(m1, m2)для блокування двох мьютексів потрібно використовувати , а не просто блокувати їх один за одним. Якщо ви заблокуєте їх один за одним, тоді, коли два потоки призначать два об'єкти в протилежному порядку, як показано вище, ви можете отримати глухий кут. Сенс у std::lockтому, щоб уникнути цього глухого кута.
Конструктор копіювання
Ви не запитували про членів копії, але ми могли б і поговорити про них зараз (якщо не ви, вони комусь знадобляться).
A(const A& a)
{
ReadLock rhs_lk(a.mut_);
field1_ = a.field1_;
field2_ = a.field2_;
}
Конструктор копіювання схожий на конструктор переміщення, за винятком того, що ReadLockпсевдонім використовується замість WriteLock. В даний час це обидва псевдоніми, std::unique_lock<std::mutex>і тому це насправді не має ніякого значення.
Але в C ++ 14 у вас буде можливість сказати це:
using MutexType = std::shared_timed_mutex;
using ReadLock = std::shared_lock<MutexType>;
using WriteLock = std::unique_lock<MutexType>;
Це може бути оптимізацією, але не точно. Вам доведеться виміряти, щоб визначити, чи є. Але за допомогою цієї зміни можна копіювати конструкцію з одного і того ж rhs в декількох потоках одночасно. Рішення C ++ 11 змушує вас робити такі потоки послідовними, навіть якщо rhs не змінюється.
Призначення копії
Для повноти, ось оператор присвоєння копії, який повинен бути досить зрозумілим після прочитання про все інше:
A& operator=(const A& a)
{
if (this != &a)
{
WriteLock lhs_lk(mut_, std::defer_lock);
ReadLock rhs_lk(a.mut_, std::defer_lock);
std::lock(lhs_lk, rhs_lk);
field1_ = a.field1_;
field2_ = a.field2_;
}
return *this;
}
І т. Д.
Будь-які інші члени або безкоштовні функції, що мають доступ Aдо стану, також повинні бути захищені, якщо ви очікуєте, що кілька потоків зможуть їх викликати одночасно. Наприклад, ось swap:
friend void swap(A& x, A& y)
{
if (&x != &y)
{
WriteLock lhs_lk(x.mut_, std::defer_lock);
WriteLock rhs_lk(y.mut_, std::defer_lock);
std::lock(lhs_lk, rhs_lk);
using std::swap;
swap(x.field1_, y.field1_);
swap(x.field2_, y.field2_);
}
}
Зверніть увагу, що якщо ви просто залежате від std::swapвиконання роботи, блокування буде мати неправильну деталізацію, блокування та розблокування між трьома ходами, які std::swapмогли б виконуватися внутрішньо.
Дійсно, обдумування swapможе дати вам уявлення про API, який вам може знадобитися, щоб забезпечити "потокобезпечний" A, який загалом буде відрізнятися від "не потокового" API через проблему "блокування деталізації".
Також зверніть увагу на необхідність захисту від "самостійної заміни". "самозаміна" повинна бути забороною. Без самоперевірки один би рекурсивно зафіксував один і той же мьютекс. Це також можна вирішити без самоперевірки, використовуючи std::recursive_mutexfor MutexType.
Оновлення
У коментарях нижче Якк досить невдоволений тим, що за замовчуванням конструює речі в конструкторах копіювання та переміщення (і він має сенс). Якщо ви ставитеся до цього питання досить сильно, настільки, що ви готові витратити на нього пам'ять, ви можете уникнути його так:
Додайте будь-які потрібні вам типи блокування в якості членів даних. Ці учасники повинні прибути перед захищеними даними:
mutable MutexType mut_;
ReadLock read_lock_;
WriteLock write_lock_;
А потім у конструкторах (наприклад, конструкторі копіювання) зробіть це:
A(const A& a)
: read_lock_(a.mut_)
, field1_(a.field1_)
, field2_(a.field2_)
{
read_lock_.unlock();
}
На жаль, Якк стер свій коментар ще до того, як я отримав можливість завершити це оновлення. Але він заслуговує на честь за те, що просунув це питання та отримав рішення у цій відповіді.
Оновлення 2
І Dyp запропонував цю слушну пропозицію:
A(const A& a)
: A(a, ReadLock(a.mut_))
{}
private:
A(const A& a, ReadLock rhs_lk)
: field1_(a.field1_)
, field2_(a.field2_)
{}