スレッド同期プリミティブの内部（ミューテックス・セマフォ・条件変数）

同期プリミティブは「待ち方」の設計である

複数スレッドが同じデータに触れるとき、競合状態（race condition）を防ぐには「ある区間は一度に一人だけ」「ある条件が満たされるまで待つ」という調整が要ります。同期プリミティブとは、この調整を提供する部品群です。設計上の核心は排他そのものより待ち方にあります。待っているスレッドをCPUを回したまま待たせる（スピン）のか、OSに頼んで寝かせる（ブロック）のか——この選択が性能とスケーラビリティを決めます。並行設計全体の地図は並行性モデル（CSP・アクター・STM）に整理してあります。

スピンロック：待つ間もCPUを回す

最も素朴な排他はスピンロックです。アトミックなフラグを test-and-set や CAS で奪い、奪えるまでループで回り続けて待ちます。

acquire:
  while CAS(lock, 0, 1) == false:   # 0(空き)を1(占有)にできるまで
    pause                            # CPUにスピン中だとヒントを出す
release:
  atomic_store(lock, 0)

スピンロックの利点は、ロック保持時間が極めて短いときに無敵な点です。寝かせて起こすにはカーネル遷移（数百〜数千サイクル）が要りますが、保持が数十サイクルなら、その場で回って待つ方が圧倒的に安い。逆に保持が長い、あるいはコア数より待ち手が多いと、スピンは純粋なCPUの浪費になります。pause 命令はスピン中であることをCPUに伝え、無駄な投機実行とパイプライン浪費を抑え、ハイパースレッディングの相方にリソースを譲ります。

ミューテックス：所有権付きの排他と二段構え

ミューテックス（mutual exclusion）は、ロックした者だけがアンロックできるという所有権を持つ排他装置です。ここがセマフォとの決定的な違いです。現代のミューテックスは競合の有無で経路を分ける二段構えで実装されます。

肝は「競合がない普通のケースではカーネルに一切入らない」ことです。空いているロックを取るのはCAS一発で済み、システムコールは発生しません。競合して初めて、待ち手をスケジューラの管理下で寝かせるためにカーネルへ降ります。この「楽観的にユーザー空間で試し、ダメなときだけ降りる」発想はロックフリー・ウェイトフリーとCAS命令の楽観的更新と同根です。違いは、ロックフリーが再試行で粘るのに対し、ミューテックスは諦めて寝る点にあります。

futex：ユーザー空間とカーネルの橋渡し

Linux でこの二段構えを支えるのが futex（fast userspace mutex） です。futex の本質は、ロックの状態語そのものはユーザー空間のメモリに置き、カーネルは「寝る／起こす」の待機列管理だけを担うという分業にあります。カーネルが提供する操作は主に二つです。

FUTEX_WAIT(addr, expected):
  # アトミックに「*addr == expected か」を確認し、
  # 真ならこのスレッドをカーネルの待機列で寝かせる。
  # 偽なら（その瞬間に値が変わった＝起こす必要なし）即座に戻る。

FUTEX_WAKE(addr, n):
  # addr で寝ている待ち手を最大 n 個起こす。

FUTEX_WAIT が「expected と一致するときだけ寝る」ことが決定的に重要です。値の確認とブロックがアトミックに行われるため、「寝ようと判断した直後に解放通知が来て取りこぼす」ロスト・ウェイクアップを構造的に防ぎます。ミューテックスの典型実装は、状態語を 0=空き / 1=占有 / 2=占有かつ待ち手あり の三値で持ち、競合がなければCASだけ、待ち手が出たときだけ futex を呼んで寝かせ、解放時は「待ち手あり」のときだけ FUTEX_WAKE を出します。これにより無競合時はカーネルに触れない設計が成立します。

条件変数：状態の変化を待つ

ミューテックスは「区間の排他」を、条件変数（condition variable）は「ある条件が成立するまでの待機」を担います。両者は必ず組で使います。条件変数は単独では機能せず、付随するミューテックスと連動して初めて正しく動きます。

# 消費者：キューが空でない、を待つ
lock(m)
while queue.is_empty():     # ← if ではなく while で再検査するのが鉄則
  wait(cv, m)               # m をアトミックに解放して寝る／起きたら m を再取得
item = queue.pop()
unlock(m)

# 生産者：要素を入れて起こす
lock(m)
queue.push(x)
signal(cv)                  # 待ち手を1つ起こす（broadcast なら全員）
unlock(m)

wait(cv, m) の中核は「ミューテックスのアンロックとスレッドの待機を不可分に行う」点です。もしこれが分割可能だと、アンロックした直後・寝る前の隙に生産者が signal を出し、その通知を取りこぼすロスト・ウェイクアップが起きます。wait はこの隙間をアトミックに閉じ、起床時にはミューテックスを取り直してから戻ります。

セマフォ：カウント付きの許可券

セマフォは整数カウンタを持つプリミティブで、二つの操作 wait（P操作・down）と signal（V操作・up）を提供します。wait はカウントを1減らし、0未満になるなら寝ます。signal はカウントを1増やし、待ち手がいれば起こします。

• カウンティングセマフォ：初期値 N で「同時に N 個まで」を表す。コネクションプールやレート制限など、有限個の資源の管理に向きます。
• バイナリセマフォ：初期値1で排他に使えますが、ミューテックスと同一ではありません。

セマフォとミューテックスの最大の違いは所有権です。ミューテックスは「ロックした者だけがアンロックできる」のに対し、セマフォの signal は誰が出してもよい。これが、片方のスレッドが wait で待ち別のスレッドが signal で通知する、生産者・消費者のシグナリングにセマフォが向く理由です。逆に排他目的でセマフォを使うと、所有権チェックがないぶん「アンロックし忘れ・二重アンロック」が静かに通ってしまいます。

モニタ：ミューテックスと条件変数を言語が束ねる

モニタ（monitor）は、ミューテックス1つと1つ以上の条件変数を、データと一緒にカプセル化した高水準構文です。Java の synchronized ＋ wait/notify、C# の lock ＋ Monitor.Wait がこれにあたります。モニタの狙いは、ロックの取得・解放を構文に埋め込んで取りこぼしを防ぎ、条件変数とミューテックスの結びつきを言語が保証することです。

モニタには起床時の意味論で二系統あります。Hoare方式は signal した瞬間に待ち手へ即座に制御を移すため、起床時に条件成立が保証されます。Mesa方式（実用上ほぼ全ての言語が採用）は signal してもシグナラが走り続け、起こされた側は後でロックを取り直すため、起きた頃には条件が崩れている可能性がある。前述の「while で再検査せよ」は、このMesa方式の帰結です。

ハイブリッドと公平性

実用のミューテックスはたいていアダプティブ（適応的）です。まず少しだけスピンしてロック保持者がすぐ手放すか様子を見て、一定回数で諦めて futex で寝ます。短時間競合はスピンで吸収し、長時間競合のCPU浪費は回避する両取りの戦略です。

もう一つの軸が公平性です。解放時に待ち列の先頭へ確実に渡すFIFO（公平）ロックは飢餓を防ぎますが、直前まで走っていたスレッドにそのまま渡すunfair ロックよりキャッシュ局所性とスループットで劣ることが多い。多くのランタイムは、ふだんは高速な unfair で動かしつつ、特定のスレッドが待たされ続けたら一時的に公平モードへ切り替える折衷を採ります。

まとめ

同期プリミティブの内部は、(1) 競合がなければユーザー空間のCASだけで完結し、競合時のみカーネルへ降りて寝る二段構え（Linuxでは futex、ランタイムでは park/unpark が橋渡し）、(2) 条件変数は必ずミューテックスと組で使い、while で条件を再検査して誤起床とMesa方式の取りこぼしを防ぐ、(3) ミューテックス（所有権付き排他）・セマフォ（カウント付き許可）・モニタ（両者の言語的束ね）は保証が異なる別物、という三点で整理できます。「待つ間にCPUを焼くか寝るか」「起こす側と寝る側の競合をどうアトミックに閉じるか」が一貫した設計テーマです。並びにまつわる可視性の保証はメモリモデルとhappens-before関係、これらの上に立つ高水準の待機はasync/awaitとコルーチンの内部実装と合わせて押さえると、同期の全体像が見通せます。