concurrency - 条件変数が誤って起動することがあるのはなぜですか?

Question

条件変数の使用方法が

lock
while not task_done
  wait on condition variable
unlock

条件変数が自発的に起動する場合があるためです。しかし、なぜそうなのか、私にはまったく理解できませんでした。過去に、その動作を持たない条件変数を作成するのは費用がかかると読んだことがありますが、それ以上のものはありません。

では、条件変数を待機しているときに誤って起こされることを心配する必要があるのはなぜですか?

Answer 1

条件変数が誤って起動するわけではありません。条件変数は、別のスレッドから通知された場合にのみ起動します。ただし、スレッドの実行が再スケジュールされるまでに、他のスレッドが待機していたリソースをすでに取得している可能性があるため、再確認する必要があります。たとえば、スレッド x、y、z のグループが、w が以前に保持していたリソース R を待機しており、x、y、z、w が条件変数を介して通信する場合... w が R で完了し、x を通知するとします。 、y、z。したがって、x、y、および z はすべて待機キューから取り出され、実行のためにスケジュールされるランキューに配置されます。x が最初にスケジュールされているとします... R を取得し、次にスリープ状態になり、次に y がスケジュールされ、y が実行されているときに、y が以前に待機していたリソース R はまだ使用できないため、y が再びスリープ状態になる必要があります。その後、z が起動し、z は R がまだ使用されていることも検出したため、z は再びスリープ状態に戻る必要があります。

ちょうど 2 つのスレッドがあり、条件変数がその 2 つだけで共有されている場合、そのチェックを実行しなくても問題ない場合があります。ただし、アプリケーションを動的にし、任意の数のスレッドにスケールアップできるようにしたい場合は、必要な追加のチェックを行う習慣を身に付けることをお勧めします (はるかに単純で心配が少ないことは言うまでもありません)。ほとんどの状況。

Answer 2

スレッドは、シグナルを受けずにウェイクアップできます。これは、スプリアス ウェイクアップと呼ばれます。しかし、なぜそれらが発生するのかは、迷信と不確実性に埋もれているように見える問題です. 私が見た理由には、スレッド化の実装が機能する方法の副作用である、またはwait.