少しのコードから始めましょう：
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でははるかに便利になる、かなり示唆に富む型エイリアスをそこに配置しました。しばらくお待ちください。そこに着きます。
あなたの質問は要約すると：
このクラスのムーブコンストラクターとムーブ代入演算子を作成するにはどうすればよいですか？
まず、moveコンストラクターから始めます。
コンストラクターの移動
メンバー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_);
}
this最初にのメンバーをデフォルトで作成し、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)2つのミューテックスを次々にロックするのではなく、を使用してロックする必要があることに注意してください。それらを次々にロックすると、上記のように2つのスレッドが2つのオブジェクトを逆の順序で割り当てると、デッドロックが発生する可能性があります。ポイント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内部で実行される3つの移動の間でロックとロック解除が行われることに注意してください。
実際、考えるswapことで、「スレッドセーフ」に提供する必要のあるAPIについての洞察を得ることができAます。これは、「ロックの粒度」の問題のため、一般に「非スレッドセーフ」APIとは異なります。
また、「セルフスワップ」から保護する必要があることにも注意してください。「セルフスワップ」は何もしないでください。セルフチェックがないと、同じミューテックスを再帰的にロックします。これは、std::recursive_mutexforを使用してセルフチェックなしで解決することもできMutexTypeます。
更新
以下のコメントでは、Yakkは、コピーおよび移動コンストラクターでデフォルトでコンストラクターを作成する必要があることにかなり不満を持っています（そして彼にはポイントがあります）。この問題について十分に強く感じて、メモリを費やしても構わないと思っている場合は、次のように回避できます。
必要なロックタイプをデータメンバーとして追加します。これらのメンバーは、保護されているデータの前に来る必要があります。
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();
}
おっと、私がこの更新を完了する前に、Yakkは彼のコメントを消去しました。しかし、彼はこの問題を推し進め、この答えに解決策をもたらしたことは称賛に値します。
アップデート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_)
{}