条件変数とモニタ・スレッド間同期の原理

モニタとは何か──排他と待ちを1つに束ねる

複数スレッドが共有データを安全に扱うには、2つの能力が要ります。相互排他（同時に1スレッドしか触れない）と、条件待ち（必要なデータがまだ揃っていなければ、譲って待つ）です。ミューテックスは前者しか提供しません。後者を素朴に「ロックを持ったままループで条件を見張る」とやると、保持者が回り続けて誰も条件を整えられず、デッドロック同然になります。

モニタ（monitor） は、この2つを1つの抽象にまとめた同期の枠組みです。モニタは「共有データ＋それを操作する手続き」を囲い、入口で自動的に相互排他をかけます。つまりモニタ内のコードを実行できるのは常に1スレッドだけ。そして条件待ちのために 条件変数（condition variable） を持ち、3つの操作を提供します。

ここで決定的に重要なのは、条件変数はそれ自身に値や状態を持たない点です。条件変数は単なる「待ち行列」であり、「キューが空でない」「バッファに空きがある」といった述語（条件）は、別の共有変数として読者自身が管理します。条件変数は「その述語が偽の間、効率よく眠って待つ」ための受け皿にすぎません。

waitの原子性──なぜ「解放・眠り・再取得」をまとめるのか

wait の意味論は一見3ステップですが、最初の2つは 不可分 でなければなりません。擬似コードで書くとこうです。

wait(cv, lock):
  アトミックに {
    lock を解放する          // ① 他スレッドが条件を整えられるように
    自分を cv の待ち行列に入れて眠る  // ②
  }
  起床後:
    lock を再取得する        // ③ モニタ内に戻る（取れるまでブロック）

①と②を分離すると、致命的な隙間が開きます。スレッドAが「条件が偽だから待とう」とロックを解放した直後、まだ待ち行列に入る前に、スレッドBが条件を整えて signal を撃ったとします。Bのsignalは「まだ待ち行列にいないA」には届かず空振りし、その後Aが眠ると——起こす人がもういない状態で永久に眠り続けます。これは futexの内部動作 で扱う lost wakeup（wakeupの取りこぼし）と同根の問題で、だからこそ「解放と待ち行列登録」を原子的に行う必要があります。

③で 必ずロックを取り直してから戻る のも本質的です。wait を抜けた地点はモニタの内側、すなわち再び相互排他下にあります。起こされたスレッドは即座に走り出すのではなく、ロックを取れるまで待ちます。この「取り直し」の存在が、次のMesa／Hoareの違いを生みます。

Mesa対Hoare──signalで「誰が即座に走るか」

signal を撃った瞬間、待っていたスレッドと撃ったスレッドの2人がモニタに入りたがります。しかしモニタの不変条件は「同時に1人だけ」。どちらを先に走らせるか で、意味論が2つに分かれます。

Hoareセマンティクス は、signal した瞬間に制御とロックを待ち手へ即座に渡します。起こされた側は「条件が成立した、まさにその瞬間の状態」を引き継ぐので、条件は確実に真です。理論的には美しいものの、実装には「signalした側を一時退避させ、待ち手が終わったら戻す」という特別なスケジューリングが要り、コストが高くなります。

Mesaセマンティクス（Xerox PARCのMesa言語に由来）は逆に、signal を「待ち行列にいる誰かを起床可能にする」だけの ヒント とします。signalした側はそのまま走り続け、起こされた待ち手は普通にロック獲得を競う一参加者になります。実装は単純で速い代わりに、起床してロックを取り直すまでの間に、第三者がモニタに入って条件を崩しうる。

spurious wakeupと再検査ループの必然性

Mesaの「条件が崩れうる」問題に加え、実装側の事情でもう1つ「理由なく起きる」現象があります。spurious wakeup（偽の起床） です。signal も broadcast も受けていないのに wait から戻ることが、仕様上起こりえます。

なぜ許容されているのか。理由は実装効率です。多くのプラットフォームで条件変数は futex などの低レベル機構の上に組まれますが、シグナル配送やプロセスの再開、複数の待ち行列の併合といった内部事情で、厳密に「signalされた1人だけ」を起こすより「余分に起こして取りこぼしを絶対に避ける」方が安全かつ高速な場面があります。POSIXは pthread_cond_wait が spurious に戻りうると明記し、移植性のあるコードはこれに備える義務を負います。

ここで重要なのは、spurious wakeupに対する防御策が、Mesaセマンティクスへの防御策とまったく同じ だという点です。どちらも「wait から戻っても条件が真とは限らない」状況であり、対処は唯一つ——起床後に条件を再検査し、偽ならまた待つ。

// 正しい形：必ず while で囲む
lock(mutex)
while (条件が偽) {        // 起床のたびに条件を読み直す
    wait(cv, mutex)
}
// ここに来たとき、条件は確実に真。かつロックを保持している
... 条件が真である前提の処理 ...
unlock(mutex)

// 壊れる形：if で書くと一度しか確認しない
lock(mutex)
if (条件が偽) {           // ← Mesaでもspuriousでも破綻する
    wait(cv, mutex)
}
... 条件が偽のまま進みうる ...
unlock(mutex)

signalかbroadcastか──取りこぼしを避ける使い分け

起こす操作の選択にも原理があります。signal は1つだけ、broadcast は全員を起こします。コストは broadcast の方が高い（サンダリングハード＝群れの暴走を招きうる）ため signal を使いたくなりますが、安全に signal で済むのは条件が限られます。

迷ったら broadcast が安全側です。全員起こしても、whileループで再検査するため進めない者はまた眠るだけで、正しさは壊れません。性能のために signal へ絞るのは、「起こすべき相手が確実に1人」だと論理的に保証できるときに限ります。なお、複数の述語を1つの条件変数に相乗りさせる設計は signal の取りこぼしを生みやすいため、条件ごとに条件変数を分ける のが定石です。

まとめ──条件変数は「述語が真になるまで眠る」部品