ミューテックス実装のテストとベンチマークの方法

タイトルにあるように、C ++のmutexのさまざまな実装を適切にテストおよびベンチマークするにはどうすればよいですか？

基本的に、2つのコアarmv7で実行されるプロジェクトのstd :: mutexのようなクラスを作成し、競合しない場合のオーバーヘッドを最小限に抑えました。今、私は上記のミューテックスをより多くの場所と異なるアーキテクチャで使用することを検討していますが、これを行う前に、

それは実際に正しいです
標準のstd :: mutexよりもパフォーマンスが悪い病理学的なケースはありません。

明らかに、いくつかの基本的な単体テストとマイクロベンチマークを書いたので、すべてがうまくいくように見えますが、マルチスレッドコードでは「動作しているように見える」ので、それほど快適ではありません。

それで、確立された静的または動的分析技術はありますか？
ミューテックスクラスの単体テストを記述する際の一般的な落とし穴は何ですか？
注目すべき典型的なエッジケースは何ですか？

実装には標準ライブラリタイプのみを使用します。これには、アトミックでの非一貫性のロードおよびストア操作が含まれます。ただし、他の実装にも同じテストハーネスを使用したいので、主に実装に依存しないアドバイスに興味があります。

c++ testing mutex

— MikeMB
ソース

必須ではないことは承知していますが、この質問の問題点についてダウンボッターからコメントをいただければ幸いです。私はSEの初心者であり、このサイトの詳細に完全に慣れているわけではありません。

— MikeMB

反対投票者ではありませんが、このサイトは完全に良い質問に対する匿名の反対投票には特に悪いと言えます。「宗教的な」理由と呼ぶものに基づいて多くの人々が賛成票を投じているように感じます。とはいえ、可能性の1つは、ツールに関する推奨事項を求めていることです。これについては、ここで眉をひそめていると思います。しかし、それは単なる推測です。そして、多くの人々が他の質問でそのようなツールを議論しました。

— user1118321

実際、「質問者のアプローチまたはロジックに同意しないため、ダウン投票」というタイトルのこのメタ投稿をチェックしてください。

— user1118321

@ user1118321：私見ではこの質問に仮定に欠陥がないため、そのメタ投稿はこの質問に適合しません。ただし、現在表示されている3つの投票のうち2つは、事前定義された「サードパーティのリソース要求」終了理由を使用しています。MikeMB、質問を編集してそれらの部分を削除しようとすることができますが、現在のフォームでは、コミュニティが広すぎるためにそれを閉じることもできると思います。質問の焦点を絞り込み、何をテストし、今までに何を試したかを具体的に尋ねると、質問が生き残る可能性が高くなります。

— Doc Brown

この質問の問題の1つは、「ツール、ライブラリ、プログラミング言語、リソース（書籍、ブログ、チュートリアル、例を含む）、または実施するプロジェクトを見つけるか、推奨する質問は、意見のある回答を集めるため、ここではオフトピックです。他の人に永続的な価値はありません。」

— デビッドハンメン

回答:

問題は複雑です：

複雑さの原因には次のものがあります。

コンテキストの切り替えがいくつ行われているか：これは、これらのテストが実行されるプラットフォームに応じて非常に重要です。一部のプラットフォームはこれを他のプラットフォームよりもうまく処理します
ミューテックスがインラインでテストされるかどうかの関数です。すなわち、ミューテックスは適切に最適化されたコードまたは最適化可能なコードでのみうまく機能しますか。
これらのミューテックスはキャッシュの局所性のために設計されていますか。キャッシュミスにより、パフォーマンスが大幅に低下するか、コンテキストの切り替えが増えます。ミューテックスが入力される前後。
ミューテックス自体がキャッシュの局所性を失います。すなわち、ミューテックス状態データが動的に割り当てられます。
ミューテックス内にコンテキストスイッチが含まれる場合、これらのミューテックスはうまく機能しますか？すなわち、io、mallocなど。
カーネル時間がmutex.ie動的メモリの割り当てと割り当て解除に含まれている場合、mutexはうまく機能しますか。
VM内で実行するときにパフォーマンスは維持されますか
ミューテックスの破壊または構築に費用がかかるか、つまり状態データが動的メモリにあるか

— クリスティアン・プレトリウス
ソース

建設/破壊の部分に同意するかどうかわからない。プログラムが常にミューテックスを作成および破壊している場合、設計デザインに（間違った）何かがあります。それ以外の場合は、ポインターに感謝します。

— MikeMB

-1

あなたのアイデアは非常に興味深いものです。ミューテックス実装のテスト対象となるコンプライアンスベンチマークです。

残念ながら、私が見る限り、mutex実装のコンプライアンスベンチマークは広く知られていません。そのため、このようなコンプライアンスベンチマークの提案を作成するという非常に興味深い問題を手に入れていると思います。

そして、あなたはベンチマーク実装の作成に関与してきたので、あなたは男です。

あなたが私に提案を許可するなら、多分あなたは片側のスレッドのためのPOSIX標準でこの研究を始め、CSPやCommunicating Sequential Processesのような同時処理の理論的文献の研究を始めることができます。この種の論文は通常、食事哲学者のような古典的な並行問題を扱っています。

それらの実装は、コンプライアンスベンチマークの興味深い部分になると思います。

— ヒルトン・フェルナンデス
ソース

私はあなたに反対票を投じませんでしたが、これは私の質問のいずれにも答えていないようです。

— MikeMB

ダウン投票しないでくれてありがとう。質問に答えていないことを残念に思います。ミューテックスのコンプライアンスベンチマークを作成することを検討している場合、私はあなたに尋ねてもいいですか？

— ヒルトンフェルナンデス

ありそうもない。そして、たとえ私が気にしている唯一の標準はc ++標準です（ただし、mutexに関してはposixと同じかもしれません）

— -MikeMB

私の以前の声明を修飾するために：もし私が自分自身のミューテックスのための良いテストスイートを思い付くなら、私はそれをオープンソースにするでしょう。「コンプライアンス」ベンチマーク-それは、とにかく静的分析で処理したほうが良いものかもしれません。

— MikeMB

ミューテックスプリミティブ用の優れたテストスイートがないことに同意します。並行処理の理論、POSIX mutexの仕様、およびmutexを使用して表現された並行アルゴリズムの3つの異なるソースから得られるはずです。それに同意しますか？

— ヒルトンフェルナンデス