私はusethreads ::sharedでperlの共有変数を使用しています。その変数は単一のスレッドからのみ変更でき、他のすべてのスレッドはその変数を「読み取る」だけです。
「読み取り」スレッドでロックする必要がありますか
{
lock $shared_var;
if ($shared_var > 0) .... ;
}
？
（「読み取り」スレッドで！）ロックせずに単純な検証を行うのは安全ではありませんか？
if ($shared_var > 0) ....
？
スカラーを設定またはフェッチするときに内部整合性を維持するためにロックは必要ありません。
あなたの特定の場合にそれが必要かどうかは、読者、他の読者、そして作家のニーズに依存します。ロックしないことはめったに意味がありませんが、あなたはあなたのニーズが何であるかを決定するために私たちに十分な詳細を提供していません。
たとえば、ライターが共有変数を更新した後、古い値を使用することは受け入れられない場合があります。手始めに、これは、一方のスレッドがまだ古い値を使用しているのに、もう一方のスレッドが新しい値を使用している状況につながる可能性があります。この状況は、これら2つのスレッドが相互作用する場合は望ましくない可能性があります。
ある時点で条件をテストすることが意味があるかどうかによって異なります。ただし、問題は、ほとんどの場合、ブールテストが他のことを意味することです。これは、前の状態を表すという条件を読み終えるまでにすでに変更されている可能性があります。
考えてみてください。それが取るに足らないテストであるなら、それはほとんど意味がありません-そしてあなたはなぜそれを作っているのか疑問に思う必要があります。それが重要なテストである場合、それはもはや存在するかもしれないし存在しないかもしれないコヒーレント状態の物語です-あなたがそれをしない限り、あなたは確かにわかりませんlock。
多くの場合、たとえばリアルタイムレポートでは、データベースがどのスナップショットを提供するかは気にせず、比較的最新のスナップショットが必要です。ただし、トランザクションロジックの一部として、コミット前の状況を完全に把握します。現在の状態が現在の状態であり、暫定的な状態にある状態でさえ明確な状態であるコードでこれを見つける可能性は低いと思います。
これが異なる可能性があるのは、キューへの周期的なアクセスだと思います。今回、1人の消費者がヘッドレコードを取得しなかった場合、次回はそのうちの1人がヘッドレコードを取得します。キューカウンターに非同期的にアクセスすることで、処理時間を節約できる可能性があります。しかし、これは、たった1回の反復のコンテキストではほとんど意味がない場合です。
上記の場合、テストでデータがあることが示唆されたとしても、キューが実際には空になる可能性があることを期待して、ロックレベルの命令を後で配置するだけです。したがって、それが単なる予備テストである場合は、テストを実際の信頼性の低いものとして扱うロジックが必要になります。