スレッドセーフルールによって提案された非const引数を使用してコンストラクターをコピーしますか？

レガシーコードの一部のラッパーがあります。

class A{
   L* impl_; // the legacy object has to be in the heap, could be also unique_ptr
   A(A const&) = delete;
   L* duplicate(){L* ret; legacy_duplicate(impl_, &L); return ret;}
   ... // proper resource management here
};

このレガシーコードでは、オブジェクトを「複製」する関数はスレッドセーフではない（同じ最初の引数を呼び出す場合）ためconst、ラッパーでマークされていません。私は現代のルールに従っていると思います：https : //herbsutter.com/2013/01/01/video-you-dont-know-const-and-mutable/

これduplicateは、そうではない詳細を除いて、コピーコンストラクタを実装する良い方法のように見えconstます。したがって、これを直接行うことはできません。

class A{
   L* impl_; // the legacy object has to be in the heap
   A(A const& other) : L{other.duplicate()}{} // error calling a non-const function
   L* duplicate(){L* ret; legacy_duplicate(impl_, &ret); return ret;}
};

それでは、この逆説的な状況から抜け出す方法は何でしょうか？

（legacy_duplicateスレッドセーフではないが、オブジェクトが終了したときにオブジェクトを元の状態のままにしておくこともできます。C関数であるため、動作は文書化されているだけで、一貫性の概念はありません。）

私は多くの可能なシナリオを考えることができます：

（1） 1つの可能性は、通常のセマンティクスでコピーコンストラクターを実装する方法がないことです。（はい、オブジェクトを移動できますが、それは必要ありません。）

（2）一方、オブジェクトをコピーすることは、単純なタイプをコピーするとソースが半分変更された状態で見つかる可能性があるという意味で、本質的にスレッドセーフではありません。

class A{
   L* impl_;
   A(A const& other) : L{const_cast<A&>(other).duplicate()}{} // error calling a non-const function
   L* duplicate(){L* ret; legacy_duplicate(impl_, &ret); return ret;}
};

（3）または、duplicateconstを宣言し、すべてのコンテキストでスレッドの安全性について嘘をつきます。（結局、レガシー関数は気にしないconstので、コンパイラーは文句を言うことさえありません。）

class A{
   L* impl_;
   A(A const& other) : L{other.duplicate()}{}
   L* duplicate() const{L* ret; legacy_duplicate(impl_, &ret); return ret;}
};

（4）最後に、ロジックに従って、const以外の引数を取るコピーコンストラクタを作成できます。

class A{
   L* impl_;
   A(A const&) = delete;
   A(A& other) : L{other.duplicate()}{}
   L* duplicate(){L* ret; legacy_duplicate(impl_, &ret); return ret;}
};

これらのオブジェクトは通常はそうではないため、これは多くのコンテキストで機能することがわかりますconst。

問題は、これが有効なルートか、それとも一般的なルートか？

それらに名前を付けることはできませんが、非constコピーコンストラクターを使用することで、直感的に多くの問題が発生することが予想されます。おそらく、この微妙さのために、それは値タイプとして適格ではありません。

（5）最後に、これはやり過ぎで、実行時のコストが非常に高くなる可能性がありますが、ミューテックスを追加できます。

class A{
   L* impl_;
   A(A const& other) : L{other.duplicate_locked()}{}
   L* duplicate(){
      L* ret; legacy_duplicate(impl_, &ret); return ret;
   }
   L* duplicate_locked() const{
      std::lock_guard<std::mutex> lk(mut);
      L* ret; legacy_duplicate(impl_, &ret); return ret;
   }
   mutable std::mutex mut;
};

しかし、これを強制されることは悲観化のように見え、クラスを大きくします。私はわかりません。私は現在（4）、（5）、または両方の組み合わせに傾いています。

- 編集

別のオプション：

（6）重複するメンバー関数の意味がないことをすべて忘れてlegacy_duplicate、コンストラクターから呼び出すだけで、コピーコンストラクターはスレッドセーフではないことを宣言します。（必要に応じて、そのタイプの別のスレッドセーフバージョンを作成しますA_mt）

class A{
   L* impl_;
   A(A const& other){legacy_duplicate(other.impl_, &impl_);}
};

編集2

これは、レガシー機能が行うことの良いモデルになる可能性があります。入力に触れることによる呼び出しは、最初の引数で表される値に関してスレッドセーフではないことに注意してください。

void legacy_duplicate(L* in, L** out){
   *out = new L{};
   char tmp = in[0];
   in[0] = tmp; 
   std::memcpy(*out, in, sizeof *in); return; 
}

私はあなたのオプション（4）と（5）の両方を含めますが、パフォーマンスに必要だと思われる場合は、スレッド安全でない動作を明示的にオプトインします。

以下は完全な例です。

#include <cstdlib>
#include <thread>

struct L {
  int val;
};

void legacy_duplicate(const L* in, L** out) {
  *out = new L{};
  std::memcpy(*out, in, sizeof *in);
  return;
}

class A {
 public:
  A(L* l) : impl_{l} {}
  A(A const& other) : impl_{other.duplicate_locked()} {}

  A copy_unsafe_for_multithreading() { return {duplicate()}; }

  L* impl_;

  L* duplicate() {
    printf("in duplicate\n");
    L* ret;
    legacy_duplicate(impl_, &ret);
    return ret;
  }
  L* duplicate_locked() const {
    std::lock_guard<std::mutex> lk(mut);
    printf("in duplicate_locked\n");
    L* ret;
    legacy_duplicate(impl_, &ret);
    return ret;
  }
  mutable std::mutex mut;
};

int main() {
  A a(new L{1});
  const A b(new L{2});

  A c = a;
  A d = b;

  A e = a.copy_unsafe_for_multithreading();
  A f = const_cast<A&>(b).copy_unsafe_for_multithreading();

  printf("\npointers:\na=%p\nb=%p\nc=%p\nc=%p\nd=%p\nf=%p\n\n", a.impl_,
     b.impl_, c.impl_, d.impl_, e.impl_, f.impl_);

  printf("vals:\na=%d\nb=%d\nc=%d\nc=%d\nd=%d\nf=%d\n", a.impl_->val,
     b.impl_->val, c.impl_->val, d.impl_->val, e.impl_->val, f.impl_->val);
}

出力：

in duplicate_locked
in duplicate_locked
in duplicate
in duplicate

pointers:
a=0x7f85e8c01840
b=0x7f85e8c01850
c=0x7f85e8c01860
c=0x7f85e8c01870
d=0x7f85e8c01880
f=0x7f85e8c01890

vals:
a=1
b=2
c=1
c=2
d=1
f=2

これは、スレッドの安全性を伝えるGoogleスタイルガイドに従いconstますが、APIを呼び出すコードは、const_cast

TLDR：複製機能の実装を修正するか、ミューテックス（または、より適切なロックデバイス、おそらくスピンロック）を導入するか、今度は、何か重いことを行う前にミューテックスがスピンするように構成されていることを確認してから、複製の実装を修正しますロックが実際に問題になった場合は、ロックを解除してください。

注目すべき重要な点は、以前は存在しなかった機能を追加していることだと思います。複数のスレッドから同時にオブジェクトを複製する機能です。

明らかに、あなたが説明した条件下では、それはバグでした-何らかの外部同期を使用せずに以前にそれを行っていた場合の競合状態。

したがって、この新しい機能の使用は、既存の機能として継承するのではなく、コードに追加するものになります。この新しい機能を使用する頻度に応じて、追加のロックを追加すると実際にコストがかかるかどうかを知っている必要があります。

また、オブジェクトの知覚された複雑さに基づいて-あなたがそれを与えている特別な扱いによって、複製手順は簡単なものではないので、パフォーマンスの面ですでにかなり高価であると仮定します。

上記に基づいて、次の2つの方法があります。

A）複数のスレッドからこのオブジェクトをコピーすると、追加のロックのオーバーヘッドが高額になるほど頻繁には発生しないことを知っています。少なくとも、既存の複製手順を使用すると、それだけで十分高額であることを考えると、おそらく簡単です。スピンロック/プレスピニングミューテックス。競合はありません。

B）複数のスレッドからのコピーが頻繁に発生し、余分なロックが問題になると思われる。次に、本当に1つのオプションしかありません-複製コードを修正します。修正しない場合は、この抽象化レイヤーでもどこか他の場所でもロックが必要になりますが、バグが必要ない場合はロックが必要です。また、私たちが確立したように、このパスでは、そのロックはコストがかかりすぎるため、唯一の選択肢は複製コードを修正することです。

私はあなたが本当に状況Aにいると思います。そして、競合しないときにパフォーマンスペナルティがほとんどないスピンロック/スピンミューテックスを追加するだけで問題なく動作します（ただし、ベンチマークを行うことを忘れないでください）。

理論的には、別の状況があります。

C）見かけ上の複製機能の複雑さとは対照的に、それは実際には取るに足らないことですが、何らかの理由で修正することはできません。それは非常に些細なことであり、争われていないスピンロックでさえ、複製に許容できないパフォーマンス低下をもたらします。並列スレッドでの複製はめったに使用されません。シングルスレッドでの複製は常に使用されるため、パフォーマンスの低下は絶対に許容できません。

この場合は、次のことをお勧めします。デフォルトのコピーコンストラクター/演算子の削除を宣言して、誰かが誤って使用しないようにします。明示的に呼び出し可能な2つの複製メソッド、スレッドセーフなものとスレッドセーフでないものを作成します。コンテキストに応じて、ユーザーに明示的に呼び出させる。繰り返しますが、実際にこの状況にあり、既存の複製の実装を修正できない場合、許容可能なシングルスレッドのパフォーマンスと安全なマルチスレッドを実現する他の方法はありません。しかし、あなたが本当にそうである可能性は非常に低いと思います。

そのミューテックス/スピンロックとベンチマークを追加するだけです。