知識マップ: スプリアスウェイクアップ ── 条件変数が「通知なしに目覚める」理由とWindowsでの正しい待ち方

記事「スプリアスウェイクアップ ── 条件変数が「通知なしに目覚める」理由とWindowsでの正しい待ち方」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

条件変数のwaitは、通知が来ていなくても戻ることがあります。Win32の公式ドキュメントは、スプリアスウェイクアップと、起こされたスレッドより先に別のスレッドが条件を消費する横取りの両方があると明記しています。3つのどの経路で戻ってきたかを呼び出し側は区別できないため、取れる戦略は「戻るたびに条件そのものを確認し、成立していなければもう一度眠る」しかありません。これはWindows固有の癖ではなく、POSIXもC++規格も同じで、ちょうど1つのスレッドだけを確実に起こす通知を厳密に実装すると条件変数のすべての操作に余分な同期コストがかかるという性能上の判断です。しかも横取りは実装を磨いても消せないため、待機側の再確認ループはどのみち必須になります。鏡像の問題が起こし損ねで、条件の確認と更新を同じロックの中で行えば防げます。

flowchart LR
    accTitle: 条件変数のスプリアスウェイクアップの知識マップ
    accDescr: waitから戻る3つの経路と呼び出し側が区別できないこと、性能とのトレードオフとして仕様が許した経緯、述語のwhileループによる対処、起こし損ねとの対比、PulseEventがカーネルAPCで通知を落とす問題を示す図
    spurious_wakeup["スプリアスウェイクアップ"]
    predicate_while_loop["述語のwhileループ再確認"]
    win32_condition_variable["Win32の条件変数"]
    stolen_wakeup["横取り(stolen wakeup)"]
    critical_section["CRITICAL_SECTION"]
    srw_lock["SRWロック(Slim Reader/Writer Lock)"]
    race_condition["競合状態(race condition)"]
    predicate_wait_overload["述語付きwait(lock, pred)"]
    std_condition_variable["std::condition_variable"]
    wait_on_address["WaitOnAddress"]
    monitor_wait_pulse["Monitor.Wait / Pulse / PulseAll"]
    lost_wakeup["起こし損ね(lost wakeup)"]
    deadlock["デッドロック(deadlock)"]
    pulseevent["PulseEvent"]
    kernel_apc["カーネルモードAPC"]
    win32_condition_variable -->|"原因になり得る"| spurious_wakeup
    win32_condition_variable -->|"原因になり得る"| stolen_wakeup
    win32_condition_variable -->|"利用する"| critical_section
    win32_condition_variable -->|"利用する"| srw_lock
    predicate_while_loop -->|"防止する"| race_condition
    predicate_wait_overload -->|"実装を担う"| predicate_while_loop
    std_condition_variable -->|"利用する"| predicate_wait_overload
    std_condition_variable -->|"原因になり得る"| spurious_wakeup
    wait_on_address -->|"原因になり得る"| spurious_wakeup
    monitor_wait_pulse -->|"原因になり得る"| stolen_wakeup
    monitor_wait_pulse -->|"前提とする"| predicate_while_loop
    lost_wakeup -->|"原因になり得る"| deadlock
    win32_condition_variable -->|"防止する"| lost_wakeup
    spurious_wakeup -.->|"原因になり得る"| race_condition
    pulseevent -->|"原因になり得る"| lost_wakeup
    kernel_apc -.->|"原因になり得る"| lost_wakeup
    win32_condition_variable -->|"の後継"| pulseevent

概念間の関係(全17件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

Win32の条件変数はスプリアスウェイクアップの原因になることがあります。条件変数はロックの解放と待機への移行を不可分に行うユーザーモードオブジェクトだが、明示的な起床と結びつかない目覚めの対象となる。 / 確度: 確立した関係 / 確認日: 2026-08-22 出典
Win32の条件変数は横取り(stolen wakeup)の原因になることがあります。通知側がWakeConditionVariableを呼んでから、起こされたスレッドがロックを再取得してwaitから戻るまでには必ず時間差がある。その間にロックを取れる第三のスレッドがいれば、条件を先に消費できてしまう。 / 確度: 確立した関係 / 確認日: 2026-08-22 出典
Win32の条件変数はCRITICAL_SECTIONを利用します。SleepConditionVariableCSは、指定したクリティカルセクションの解放と条件変数での待機を不可分に行い、目覚めるときはロックを再取得してから戻る。 / 確度: 確立した関係 / 確認日: 2026-08-22 出典
Win32の条件変数はSRWロック(Slim Reader/Writer Lock)を利用します。SleepConditionVariableSRWを使えば、クリティカルセクションの代わりにSRWロックと組み合わせて同じ待ち合わせができる。どちらか一方のロックと組で使う。 / 確度: 確立した関係 / 確認日: 2026-08-22 出典
述語のwhileループ再確認は競合状態(race condition)を防ぎます。スプリアスウェイクアップも横取りも発生自体は消せないが、waitから戻るたびに待っていた条件そのものを確認し、成立していなければもう一度眠ることで、条件不成立のまま処理が進むことを防げる。3つのどの経路で戻ってきたかを呼び出し側は区別できないため、これが唯一の戦略になる。公式の生産者・消費者キューの使用例も待機をwhileループで書いている。 / 確度: 確立した関係 / 確認日: 2026-08-22 出典出典
述語付きwait(lock, pred)は述語のwhileループ再確認の実装を担います。述語なしのwaitはnotify_one / notify_allでシグナルされるまでブロックするがスプリアスに目覚めることもあり、述語付きのwait(lock, pred)は実質的に while (!pred()) wait(lock); を実行する。 / 確度: 確立した関係 / 確認日: 2026-08-22 出典出典
std::condition_variableは述語付きwait(lock, pred)を利用します。C++で推奨される述語付きwaitは、whileで囲む規律をライブラリが肩代わりする形にほかならない。新規コードの既定はこちらになる。 / 確度: 確立した関係 / 確認日: 2026-08-22 出典
std::condition_variableはスプリアスウェイクアップの原因になることがあります。スプリアスウェイクアップはPOSIXもWindowsもC++規格もそろって許した仕様で、ちょうど1つのスレッドだけを確実に起こす通知を厳密に実装すると、特にマルチプロセッサ環境で条件変数のすべての操作に余分な同期コストがかかるためである。ループの強制はコードを自己文書化し、より堅牢にするとも述べられている。 / 確度: 確立した関係 / 確認日: 2026-08-22 出典出典
WaitOnAddressはスプリアスウェイクアップの原因になることがあります。アドレスの値が変わるのを待つ最下層に近いAPIですら、シグナル時に戻ることは保証されるがそれ以外の理由で戻ることも許されている。低メモリ状態や過去のwakeの放棄が早期に目覚める例として挙げられ、使用例そのものが値を比較し直すwhileループの形をしている。 / 確度: 確立した関係 / 確認日: 2026-08-22 出典
Monitor.Wait / Pulse / PulseAllは横取り(stolen wakeup)の原因になることがあります。PulseAllは待機キューのスレッドをレディキューに移し、ロックが解放されるとレディキューのスレッドがロックを取り直せた順にWaitから戻る。取り直すまでの間に別のスレッドが条件を消費できる点はWin32と同じで、起こされたスレッドは待機に入った原因の条件を評価し直し、必要ならもう一度Waitを呼ぶ使い方が想定されている。 / 確度: 確立した関係 / 確認日: 2026-08-22 出典出典
Monitor.Wait / Pulse / PulseAllは述語のwhileループ再確認を前提とします。.NETでも規律は変わらず、whileで条件を確認してからWaitに戻る。 / 確度: 確立した関係 / 確認日: 2026-08-22 出典
起こし損ね(lost wakeup)はデッドロック(deadlock)の原因になることがあります。待機側がロックの外で条件を見て待機に入ろうとした隙間に通知側が状態を更新して通知を送ると、通知は待機者のいない条件変数へ向けて発射されて消え、待機側は二度と来ない通知を待ち続ける。 / 確度: 確立した関係 / 確認日: 2026-08-22 出典
Win32の条件変数は起こし損ね(lost wakeup)を防ぎます。条件変数の待機APIがロックの解放と眠りへの移行を不可分に行うよう設計されているのは、まさにこの隙間を閉じるためで、ロックの規律を守っている限り起きない。 / 確度: 確立した関係 / 確認日: 2026-08-22 出典
スプリアスウェイクアップは競合状態(race condition)の原因になることがあります。ifで1回だけ確認して待機に入るコードは、スプリアスウェイクアップか横取りが起きた瞬間に条件不成立のまま処理が進み、空のキューからの取り出しや未初期化データの参照といった、たまにしか出ないクラッシュ・データ破損になる。 / 確度: 条件付きの関係 / 確認日: 2026-08-22 出典
PulseEventは起こし損ね(lost wakeup)の原因になることがあります。待機中のスレッドがカーネルモードAPCで一時的に待機状態から外され、APC完了後に戻ることがある。その一瞬の間にPulseEventが呼ばれると、そのスレッドは「呼ばれた瞬間に待機していた者」に含まれず起こされない。whileループでも救えない、通知そのものが失われる問題である。 / 確度: 確立した関係 / 確認日: 2026-08-22 出典
カーネルモードAPCは起こし損ね(lost wakeup)の原因になることがあります。カーネルAPCはプリエンプティブに実行され、待機APIを戻すことなくシステムが内部的に待機を中断する。その一瞬の間にPulseEventが呼ばれると、そのスレッドは「呼ばれた瞬間に待機していた者」に含まれず起こされない。カーネルAPCはOSが内部的に使うもので、アプリ側から制御できない。 / 確度: 条件付きの関係 / 確認日: 2026-08-22 出典出典
Win32の条件変数はPulseEventの後継に当たります。PulseEventは信頼できないため使うべきではなく、主に後方互換のために存在し、代わりに条件変数を使うべきだと明言されている。静的解析の警告C28648にもなっている。 / 確度: 確立した関係 / 確認日: 2026-08-22 出典出典

主要概念の定義

スプリアスウェイクアップ: 通知がないのに条件変数の待機から目覚めてしまう現象。
述語のwhileループ再確認: 待機操作から戻るたびに待っていた条件そのものを確認し、成立していなければもう一度待つ書き方。
Win32の条件変数: InitializeConditionVariableで作り、SleepConditionVariableCS／SRWで待ち、WakeConditionVariableで起こすWin32の待ち合わせ機構。
述語付きwait(lock, pred): 実質的に while (!pred()) wait(lock); を実行する、C++の条件変数の待機オーバーロード。
std::condition_variable: ミューテックスと組み合わせて、条件が満たされるまでスレッドを待たせるC++の同期プリミティブ。
WaitOnAddress: 指定アドレスの値が変わるのを待つ、条件変数より原始的な待機API。シグナル時に戻ることは保証されるが、それ以外の理由で戻ることも許されている。
Monitor.Wait / Pulse / PulseAll: ロックを解放して待機キューに入り、Pulse系で起こされてレディキューへ移り、ロックを取り直してから戻る.NETの待ち合わせ。
起こし損ね(lost wakeup): 待機側がロックの外で条件を見てから待機に入るまでの隙間に通知が通り過ぎ、二度と来ない通知を待ち続けること。
PulseEvent: 手動リセットイベントで「今待っている全員を起こしてすぐ非シグナルに戻す」API。マイクロソフト自身が信頼できないため使うべきでないとしている。
カーネルモードAPC: プリエンプティブに実行され、待機APIを戻すことなくシステムが内部的に待機を中断・再開させる仕組み。アプリ側から制御できない。

機械可読データ

JSON-LD / Turtle ── この記事の知識グラフ全体
概念一覧 / 語彙(述語)の定義

このデータセットについて

作成: 合同会社小村ソフト
ライセンス: CC BY 4.0 ── 出典(合同会社小村ソフト)とライセンスへのリンクを明示し、改変した場合はその旨を示すことを条件に、再配布・改変を含めて再利用できます
最終確認日: 2026-08-22 ── 収録する関係のうち、最後に出典と照合した日

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。