1 クリティカルセクションの概要
1.1 定義と目的
クリティカルセクションとは、並行に実行される複数の処理が、共有データや共有資源へ同時アクセスすることで、不整合や破壊的な結果が生じうる区間を指す。目的は、同時実行による競合を抑止し、処理の正当性（正しい状態遷移や整合性の保持）を保証することにある。加えて、実行順序が変動しても結果が安定するように振る舞いを設計する点が重視される。
1.2 共有リソースと競合の関係
競合は、少なくとも一方が更新（書き込み）を行う共有リソースに対して、複数の実行主体が重なって操作することで発生する。共有状態には、メモリ上の変数、ファイル、データベースの行、ネットワーク接続のような実体が含まれる。クリティカルセクションは、こうした共有領域へのアクセスを「制御された範囲」として切り出し、相互の干渉を最小化するために用いられる。
1.3 典型的な不具合の例
代表的な不具合には、競合状態による更新の取りこぼし、途中状態の参照、順序の逆転による整合性破壊がある。例えば、残高の加減算を行う処理が同時実行されると、読み取り値が同一になり、その後の書き込みが衝突して誤差が生じることがある。また、ロックで保護されていない部分が残っている場合、整合性が崩れたまま処理が継続し、後段で原因特定が難しくなる。
2 同期の基本概念
2.1 相互排他（ミューテックス）
相互排他（ミューテックス）は、ある共有対象に対し、同時に実行できる処理を一つに制限する仕組みである。重要なのは「排他制御の単位」と「保護範囲の設計」であり、保護すべき区間が過剰に広いと待ちが増え、狭すぎると整合性が担保されない。ミューテックスは通常、ロックの取得と解放という明確なライフサイクルを伴う。
2.1.1 ロック取得と解放の流れ
ロック取得は、共有資源へ入る前に行い、取得できない場合は待機するのが一般的である。解放は、クリティカルセクションから退出するタイミングで実行される。実装では、ロック獲得の成否、待機条件、タイムアウトや割り込みの扱いなどの挙動が仕様として定義されることが多い。誤って解放を行わないと、他の実行主体が永久に進めなくなる。
2.1.1.1 RAII等による安全な解放設計
RAII（Resource Acquisition Is Initialization）のような手法では、オブジェクトの生成時にロックを取得し、破棄時に自動的に解放する。これにより例外や早期リターンがあっても、解放漏れのリスクが下がる。設計上の利点は、解放責務が呼び出し側に散らばらず、読みやすさと安全性が高まりやすい点にある。
2.2 条件変数と待機の考え方
条件変数は、「ある条件が成立するまで待つ」というパターンを実現するための同期プリミティブである。待機側はミューテックスなどと組み合わせて条件を検査し、条件が満たされるまでブロックする。目標は、無駄なポーリングを避けつつ、状態変化に応じて待ちを解除することである。注意点として、待機から復帰した後に条件を再確認する実装が一般的とされる（復帰時点で条件が変わっている可能性があるため）。
2.3 セマフォとリソースカウント
セマフォは、同時に利用できる資源の個数をカウントとして管理する同期機構である。ミューテックスが「1つだけ」という制約を実現することが多いのに対し、セマフォは複数枠（並列度）を表現できる。例えば、接続プールやワーカ数の上限などに用いられることが多い。カウントが減少して枠が不足すると待機が発生し、資源の返却により増加して進行が可能になる。
3 実装パターン
3.1 ロックベース実装
3.1.1 単一ロック設計
単一ロック設計では、対象全体を一つのミューテックスで保護する。実装は比較的単純になり、整合性の保証も理解しやすい。一方で競合が増える場面では、待機時間が伸びてスループットが低下しやすい。したがって、保護範囲の最適化やクリティカルセクションの短縮が重要になる。
3.1.2 複数ロック設計
複数ロック設計では、共有状態を複数の独立領域に分割し、それぞれに別のロックを割り当てる。これにより同時実行性が高まり、局所的な競合に留められる可能性がある。反面、複数ロックの獲得順序が設計に影響し、整合性は保てても進行不能に陥る危険が増える。よって、ロック順序の統一や獲得階層の明文化が不可欠になる。
3.2 ロックフリー・待機フリーの考え方
3.2.1 アトミック操作の利用
ロックフリー／待機フリーは、ロックによる待機を避ける方向性として知られる。基本となるのはアトミック操作（読み取り・更新を一塊として扱う命令）の利用である。これにより、競合時でも中間状態を外部に見せにくくし、進行を保証する設計が可能になる。ただし、アルゴリズム選定と正当性証明が複雑になりがちで、実装ミスが潜在的に深刻な不具合へつながる。
3.2.2 ハザードポインタ等の手法
ロックを使わない設計では、参照中のノードやオブジェクトが別スレッドにより回収される危険がある。これを扱うために、ハザードポインタのような手法や、世代管理に基づく方式が用いられることがある。目的は、使用中のメモリ領域を安全に生存させるための整合性確保である。管理コストや実装の複雑さは増える傾向があるため、用途に応じた判断が必要になる。
4 設計・運用上の注意点
4.1 デッドロックとその回避策
デッドロックは、複数の実行主体が互いの解放待ちとなり、進行が停止する状態である。典型は、異なる順序でロックを獲得する場合に発生する。回避策としては、獲得順序を統一する、同時に保持するロック数を最小化する、タイムアウトやリトライ戦略を設けるなどがある。さらに、保護対象の粒度を見直してクリティカルセクションを縮めることも有効である。
4.2 ライブロックと飢餓状態への対処
ライブロックは、状態は変化しているのに誰も前へ進めない状況を指す。例えば、競合を検知して即座に解除し続ける設計では、衝突のたびに譲り合いが続いて進まないことがある。飢餓状態は、一部の処理が継続的に後回しにされ、結果として十分な機会を得られない現象である。対処としては、待機戦略の調整（公平性の導入、バックオフの設計、優先順位制御など）が用いられる。
4.3 性能評価（待ち時間・スループット）
性能は、待ち時間だけでなくスループットやレイテンシの分布で評価するのが望ましい。ロックは競合を抑える一方で待機コストを生み、過度な保護範囲は性能劣化につながる。観測可能性の観点から、ロック待機時間、競合頻度、平均保持時間、タイムアウト発生率などを指標として収集すると、ボトルネックの特定が容易になる。負荷条件（ワークロード特性）ごとの差異にも注意が必要である。
4.4 デバッグと検証（再現性、ログ、テスト）
並行性の不具合は再現性が低いことが多く、検証には工夫が要る。ログは、ロック取得・解放のイベント、待機の開始と解除、例外経路などを追跡可能にする。テストでは、負荷を高めた条件、実行順序が揺れやすい条件、遅延挿入による探索などを組み合わせることがある。加えて、静的解析や動的解析、レース検出ツールの活用により、競合の可能性を体系的に潰すアプローチが取られる。