並行処理と排他制御

1. 共有データの破壊：競合状態（Race Condition）

複数のスレッドが、同じメモリ上のデータに対して同時に読み込みや書き込み（更新）を行おうとするとき、実行のタイミング（スレッドの切り替え順序）によって結果がめちゃくちゃになってしまう現象を競合状態（Race Condition：レースコンディション）と呼びます。

具体的な例として、「銀行口座の残高（初期値 1,000円）から、同時に1,000円を引き出す」という処理を考えてみましょう。

スレッドAとスレッドBがほぼ同時に処理を開始した場合、スレッドAが残高を読み取って「引出可能（1,000円 ≧ 1,000円）」と判定した直後、まだAが書き込みを行う前にスレッドBが割り込んできます。スレッドBもまた古い残高「1,000円」を読み取るため、「引出可能」と誤って判定してしまいます。

結果として、AもBも1,000円ずつの引き出しに成功し、銀行口座からは合計2,000円が引き出されたのにもかかわらず、最終残高は「0円」と記録されます。銀行にとっては大赤字の恐ろしいバグです。

2. 解決策：排他制御（Mutual Exclusion）とロック

この問題を避けるためには、「あるスレッドがデータを操作している間は、他のスレッドは手出しできないようにする」というルールが必要です。この仕組みを排他制御（Mutual Exclusion）と呼びます。

排他制御を行うため、同時に1つのスレッドしか実行してはいけないコードの領域（クリティカルセクション）に対して、「ロック（Lock：またはミューテックス/Mutex）」と呼ばれる電子的な「鍵」をかけます。

1. スレッドAが口座データの操作を開始する前に、その口座の「鍵」を獲得します（ロック状態にする）。
2. スレッドBが割り込んできて口座を操作しようとしますが、すでにロックされている（鍵がない）ため、Bは処理を一時停止し、Aが鍵を返すのを待ちます（ブロック状態）。
3. Aが「読み取り ➔ 判定 ➔ 書き込み」の処理をすべて終えたら、鍵を返却します（アンロック）。
4. 待機していたBがようやく鍵を獲得し、安全に更新された新しい残高「0円」に対して処理を開始します。このとき、Bは「引出不可（0円 ＜ 1,000円）」と正しく判定でき、2重引き出しは防がれます。

3. 排他制御の副作用：デッドロック（Deadlock）

ロックを使えば安全になりますが、ロックの掛け方を間違えると、プログラムが完全にフリーズして動かなくなるバグを引き起こします。その代表例がデッドロック（Deadlock）です。

デッドロックは、2つのスレッドが互いに相手が持っている鍵を永久に待ち続けることで発生します。

スレッド1はスレッド2が鍵Bを返すのを待ち、スレッド2はスレッド1が鍵Aを返すのを待っています。お互いに相手の解放を待ち続けるため、どちらの処理も1ミリも前に進まなくなります。これがデッドロックです。

デッドロックを防ぐためには、「常に決められた順序でしか鍵を獲得しない（例：必ずAを獲ってからBを獲る）」といった厳格な設計ルールが必要になります。

次のセクションでは、OSのもう1つの重要な機能である、データを消えない形でディスク上に格納し管理する「ファイルシステム」の仕組みについて学びます。