Zacznijmy od fragmentu kodu:
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:
...
Umieściłem tam kilka dość sugestywnych aliasów typów, których tak naprawdę nie wykorzystamy w C ++ 11, ale staną się znacznie bardziej przydatne w C ++ 14. Cierpliwości, dotrzemy na miejsce.
Twoje pytanie sprowadza się do:
Jak napisać konstruktor przenoszenia i operator przypisania przenoszenia dla tej klasy?
Zaczniemy od konstruktora przenoszenia.
Move Constructor
Zwróć uwagę, że członek mutexzostał utworzony mutable. Ściśle mówiąc, nie jest to konieczne dla członków ruchu, ale zakładam, że chcesz również kopiować członków. Jeśli tak nie jest, nie ma potrzeby tworzenia muteksu mutable.
Podczas konstruowania Anie musisz blokować this->mut_. Ale musisz zablokować mut_obiekt, z którego konstruujesz (przenieść lub skopiować). Można to zrobić w następujący sposób:
A(A&& a)
{
WriteLock rhs_lk(a.mut_);
field1_ = std::move(a.field1_);
field2_ = std::move(a.field2_);
}
Zauważ, że musieliśmy domyślnie skonstruować elementy składowe thisfirst, a następnie przypisać im wartości dopiero po a.mut_zablokowaniu.
Przenieś przypisanie
Operator przypisania przeniesienia jest znacznie bardziej skomplikowany, ponieważ nie wiadomo, czy inny wątek uzyskuje dostęp do lewego lub prawego skrzydła wyrażenia przypisania. Ogólnie rzecz biorąc, musisz wystrzegać się następującego scenariusza:
x = std::move(y);
y = std::move(x);
Oto operator przypisania ruchu, który prawidłowo chroni powyższy scenariusz:
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;
}
Zauważ, że należy użyć std::lock(m1, m2)do zablokowania dwóch muteksów, zamiast po prostu blokować je jeden po drugim. Jeśli zablokujesz je jeden po drugim, to gdy dwa wątki przypiszą dwa obiekty w odwrotnej kolejności, jak pokazano powyżej, możesz uzyskać zakleszczenie. Chodzi o std::lockto, aby uniknąć tego impasu.
Copy Constructor
Nie pytałeś o członków kopii, ale równie dobrze możemy porozmawiać o nich teraz (jeśli nie ty, ktoś będzie ich potrzebował).
A(const A& a)
{
ReadLock rhs_lk(a.mut_);
field1_ = a.field1_;
field2_ = a.field2_;
}
Konstruktor kopiujący wygląda podobnie do konstruktora przenoszenia, z wyjątkiem tego, że ReadLockalias jest używany zamiast WriteLock. Obecnie oba pseudonimy, std::unique_lock<std::mutex>więc nie ma to większego znaczenia.
Ale w C ++ 14 będziesz mieć możliwość powiedzenia tego:
using MutexType = std::shared_timed_mutex;
using ReadLock = std::shared_lock<MutexType>;
using WriteLock = std::unique_lock<MutexType>;
Może to być optymalizacja, ale nie zdecydowanie. Będziesz musiał zmierzyć, aby określić, czy tak jest. Ale dzięki tej zmianie można kopiować konstrukcję z tego samego prawa w wielu wątkach jednocześnie. Rozwiązanie C ++ 11 zmusza cię do tworzenia takich wątków sekwencyjnie, mimo że prawa oś nie są modyfikowane.
Kopiuj przypisanie
Dla kompletności, oto operator przypisania kopiowania, który powinien być dość oczywisty po przeczytaniu wszystkiego innego:
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;
}
Itd.
Wszyscy inni członkowie lub bezpłatne funkcje, które mają dostęp do Astanu, również będą musiały być chronione, jeśli oczekujesz, że wiele wątków będzie mogło wywoływać je jednocześnie. Na przykład tutaj 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_);
}
}
Zwróć uwagę, że jeśli polegasz tylko na std::swapwykonaniu zadania, blokowanie będzie miało niewłaściwą szczegółowość, blokowanie i odblokowywanie między trzema ruchami, które std::swapbyłyby wykonywane wewnętrznie.
Rzeczywiście, myślenie o tym swapmoże dać ci wgląd w API, które możesz potrzebować, aby zapewnić "bezpieczne wątkowo" A, które ogólnie będzie różniło się od "niegwintowanego" API, ze względu na problem "granularności blokowania".
Zwróć również uwagę na potrzebę ochrony przed „samodzielną wymianą”. „Self-swap” nie powinno być opcją. Bez samokontroli można by rekurencyjnie zablokować ten sam muteks. Można to również rozwiązać bez samokontroli, używając std::recursive_mutexfor MutexType.
Aktualizacja
W komentarzach poniżej Yakk jest dość niezadowolony z konieczności domyślnego konstruowania rzeczy w konstruktorach kopiowania i przenoszenia (i ma rację). Jeśli czujesz się wystarczająco mocno w tej kwestii, tak bardzo, że chcesz poświęcić jej pamięć, możesz tego uniknąć w następujący sposób:
Dodaj dowolne typy blokad, których potrzebujesz jako członków danych. Członkowie ci muszą poprzedzić chronione dane:
mutable MutexType mut_;
ReadLock read_lock_;
WriteLock write_lock_;
A potem w konstruktorach (np. Konstruktorze kopiującym) zrób tak:
A(const A& a)
: read_lock_(a.mut_)
, field1_(a.field1_)
, field2_(a.field2_)
{
read_lock_.unlock();
}
Ups, Yakk usunął swój komentarz, zanim udało mi się ukończyć tę aktualizację. Ale on zasługuje na uznanie za forsowanie tej kwestii i znalezienie rozwiązania w tej odpowiedzi.
Zaktualizuj 2
I dyp wpadł na tę dobrą sugestię:
A(const A& a)
: A(a, ReadLock(a.mut_))
{}
private:
A(const A& a, ReadLock rhs_lk)
: field1_(a.field1_)
, field2_(a.field2_)
{}