Beginnen wir mit ein bisschen Code:
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:
...
Ich habe dort einige eher suggestive Typ-Aliase eingefügt, die wir in C ++ 11 nicht wirklich nutzen, aber in C ++ 14 viel nützlicher werden. Sei geduldig, wir werden dort ankommen.
Ihre Frage lautet:
Wie schreibe ich den Verschiebungskonstruktor und den Verschiebungszuweisungsoperator für diese Klasse?
Wir beginnen mit dem Verschiebungskonstruktor.
Konstruktor verschieben
Beachten Sie, dass das Mitglied mutexerstellt wurde mutable. Genau genommen ist dies für die Umzugsmitglieder nicht erforderlich, aber ich gehe davon aus, dass Sie auch Kopiermitglieder möchten. Ist dies nicht der Fall, muss der Mutex nicht erstellt werden mutable.
Beim Konstruieren Amüssen Sie nicht sperren this->mut_. Sie müssen jedoch mut_das Objekt sperren, aus dem Sie erstellen (verschieben oder kopieren). Dies kann folgendermaßen geschehen:
A(A&& a)
{
WriteLock rhs_lk(a.mut_);
field1_ = std::move(a.field1_);
field2_ = std::move(a.field2_);
}
Beachten Sie, dass wir die Mitglieder von thiszuerst standardmäßig erstellen und ihnen dann erst Werte zuweisen mussten, nachdem sie a.mut_gesperrt wurden.
Zuordnung verschieben
Der Verschiebungszuweisungsoperator ist wesentlich komplizierter, da Sie nicht wissen, ob ein anderer Thread auf die lhs oder rhs des Zuweisungsausdrucks zugreift. Im Allgemeinen müssen Sie sich vor dem folgenden Szenario schützen:
x = std::move(y);
y = std::move(x);
Hier ist der Verschiebungszuweisungsoperator, der das obige Szenario korrekt schützt:
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;
}
Beachten Sie, dass Sie std::lock(m1, m2)die beiden Mutexe sperren müssen , anstatt sie nur nacheinander zu sperren. Wenn Sie sie nacheinander sperren, können Sie einen Deadlock erhalten, wenn zwei Threads zwei Objekte in entgegengesetzter Reihenfolge wie oben gezeigt zuweisen. Es std::lockgeht darum, diesen Deadlock zu vermeiden.
Konstruktor kopieren
Sie haben nicht nach den Kopienmitgliedern gefragt, aber wir könnten genauso gut jetzt darüber sprechen (wenn nicht Sie, wird jemand sie brauchen).
A(const A& a)
{
ReadLock rhs_lk(a.mut_);
field1_ = a.field1_;
field2_ = a.field2_;
}
Der Kopierkonstruktor ReadLockähnelt stark dem Verschiebungskonstruktor, außer dass der Alias anstelle des verwendet wird WriteLock. Derzeit sind diese beiden Alias std::unique_lock<std::mutex>und so macht es keinen wirklichen Unterschied.
In C ++ 14 haben Sie jedoch die Möglichkeit, Folgendes zu sagen:
using MutexType = std::shared_timed_mutex;
using ReadLock = std::shared_lock<MutexType>;
using WriteLock = std::unique_lock<MutexType>;
Dies kann eine Optimierung sein, aber nicht definitiv. Sie müssen messen, um festzustellen, ob dies der Fall ist. Mit dieser Änderung kann man jedoch Konstrukte aus denselben rhs in mehreren Threads gleichzeitig kopieren . Die C ++ 11-Lösung zwingt Sie, solche Threads sequentiell zu machen, obwohl die rhs nicht geändert werden.
Zuordnung kopieren
Der Vollständigkeit halber hier der Kopierzuweisungsoperator, der nach dem Lesen von allem anderen ziemlich selbsterklärend sein sollte:
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;
}
Und soweiter und sofort.
Alle anderen Mitglieder oder freien Funktionen, die auf Aden Status zugreifen , müssen ebenfalls geschützt werden, wenn Sie erwarten, dass mehrere Threads sie gleichzeitig aufrufen können. Zum Beispiel hier 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_);
}
}
Beachten Sie, dass, wenn Sie nur von std::swapder std::swapAusführung des Auftrags abhängig sind , die Sperrung in der falschen Granularität erfolgt und zwischen den drei Bewegungen, die intern ausgeführt werden , gesperrt und entsperrt wird .
Wenn Sie darüber nachdenken, erhalten swapSie möglicherweise einen Einblick in die API, die Sie möglicherweise benötigen, um eine "thread-sichere" API bereitzustellen A, die sich aufgrund des Problems der "Sperrgranularität" im Allgemeinen von einer "nicht thread-sicheren" API unterscheidet.
Beachten Sie auch die Notwendigkeit, sich vor "Selbsttausch" zu schützen. "Selbsttausch" sollte ein No-Op sein. Ohne den Selbsttest würde man denselben Mutex rekursiv sperren. Dies könnte auch ohne Selbsttest mit std::recursive_mutexfor gelöst werden MutexType.
Aktualisieren
In den Kommentaren unten ist Yakk ziemlich unglücklich darüber, dass er standardmäßig Dinge in den Kopier- und Verschiebungskonstruktoren konstruieren muss (und er hat einen Punkt). Wenn Sie sich zu diesem Thema so stark fühlen, dass Sie bereit sind, sich daran zu erinnern, können Sie es folgendermaßen vermeiden:
Fügen Sie alle Sperrtypen hinzu, die Sie als Datenelemente benötigen. Diese Mitglieder müssen vor den zu schützenden Daten stehen:
mutable MutexType mut_;
ReadLock read_lock_;
WriteLock write_lock_;
Und dann tun Sie dies in den Konstruktoren (z. B. dem Kopierkonstruktor):
A(const A& a)
: read_lock_(a.mut_)
, field1_(a.field1_)
, field2_(a.field2_)
{
read_lock_.unlock();
}
Hoppla, Yakk hat seinen Kommentar gelöscht, bevor ich die Gelegenheit hatte, dieses Update abzuschließen. Aber er verdient Anerkennung dafür, dass er dieses Problem vorangetrieben und eine Lösung für diese Antwort gefunden hat.
Update 2
Und dyp kam auf diesen guten Vorschlag:
A(const A& a)
: A(a, ReadLock(a.mut_))
{}
private:
A(const A& a, ReadLock rhs_lk)
: field1_(a.field1_)
, field2_(a.field2_)
{}