コードにいくつかの単体テストを追加したいと考えています。また、実行中のコードに常にアクセスできるとは限らないプラグインをロードします。私が本当にチェックしたいテストは、呼び出している関数がロックフリーかどうかです。
私のプログラムのポイントAとBの間にロックフリーでない関数への呼び出しがあったかどうかをテストするフックまたは方法はありますか?
もう 1 つのそれほど複雑でない関数は、すべての呼び出しをロック関数 (ロック、システム コールなど) にフックする方法です。Windowsでmallocの呼び出しをフックする方法は知っていますが、他には何もありません。
ご協力ありがとうございました
ロックやそれに類するものを装備しなければ、それを行うことはできないと確信しています。
ロック関数の呼び出しがテストで異なる動作を引き起こす多くのシナリオを考え出すことができます [おそらく「テストを特定するための特別なテストモード」が有効になっている場合のみ] - たとえば、100ms のスリープを追加します。ロック方法に切り替え、別のロックされた機能を使用してみて、「ロックの競合なし」と時間を比較してください。
または、ロックする呼び出しのカウントを保持し、関数の前後のカウントが同じかどうか (または、関数がlock特定の回数を呼び出すことになっている場合は、予想された量だけ増加したかどうか) を確認することもできます。
しかし、ロック機構に介入しない一般的な方法は、不可能だと確信しています。
もちろん、どのコードがロックを呼び出し、どのコードがロックを呼び出していないかに関するコードレビューと明確なドキュメントも役立ちます。また、エラーを発見する優れたレビュアーも役に立ちます。
他の人がすでに答えているように、アルゴリズムがロックフリーかどうかをテストすることはできません。ただし、マルチスレッド環境で一貫して動作することをテストすることは可能です。この分野での私の経験は、ロックフリー キュー (私自身が書いたものですが、学術論文に基づいています) のみを使用しているため、私のテストは、役に立つかもしれないし、役に立たないかもしれないキューに基づいています。
複数のスレッドを使用して、キューをハンマーでテストしました。
私のテストでは、リーダーとライターの数も変化させました。リーダーとライターの比率に応じて、キューの動作が異なります。ライターよりもリーダーの方が多いと、通常はキューがほぼ空になりますが、逆の場合は、ライターが書き込みを停止するまでキューが継続的に拡張されます。
ポイント 2 は、高負荷下での応答時間の分散に基づいて、アルゴリズムがロックフリーであるかどうかを一般的に判断できるため、関心があるかもしれません。負荷が高くても応答時間が速い場合は、アルゴリズムがロックフリーであると推測できます。または、少なくともそうでない場合は、あたかもそうであるかのように動作します。