変更要約: 初版
2.5OSとミドルウェア
FE/SGのタスク管理・排他制御の基礎を踏まえ、スケジューリング方式の比較（ラウンドロビン／優先度／SJF）、セマフォによる排他制御の仕組みとデッドロックの発生条件（4条件）・回避策を深掘りします。さらに仮想記憶とプロセス管理の関係、ミドルウェア（DBMS/APサーバ/メッセージキュー）の役割、OSSのライセンス（GPL／MIT等）まで扱います。
FE/SGでは「セマフォで排他制御する」「デッドロックが起こりうる」という現象レベルの理解で足りますが、応用情報ではデッドロックがなぜ・どの条件が揃うと発生するのか、そしてその条件をどう崩せば回避できるのかという、より構造的な理解が求められます。ミドルウェアやOSSライセンスの実務知識も併せて整理します。
2.5.1スケジューリング方式の比較
| 方式 | 選び方の基準 | 弱点 |
|---|---|---|
| ラウンドロビン | 一定時間ずつ公平に割り当て、応答性重視の対話型システム向け | タイムクウォンタムが短すぎると切替（コンテキストスイッチ）の頻発でオーバーヘッド増 |
| 優先度方式 | 緊急度に差がある処理が混在する環境向け | 低優先度タスクが実行され続けない==飢餓状態==のリスク |
| SJF（最短時間優先） | 平均待ち時間を最小化したいバッチ処理向け | 実行時間の事前把握が難しく、長いジョブが後回しにされ続ける==飢餓状態==のリスク |
- SJF（Shortest Job First、最短時間優先方式）＝実行時間が最も短いと見込まれるタスクを優先的に実行するスケジューリング方式で、理論上は平均待ち時間を最小化できるという性質があります。ただし実際の実行時間を事前に正確に見積もることは難しく、また実行時間の長いタスクがいつまでも後回しにされる飢餓状態に陥りうるという弱点があります。
- 優先度方式とSJFに共通する飢餓状態（スターベーション）とは、特定の条件（優先度が低い、実行時間が長い等）に該当するタスクがいつまでもCPUを割り当てられない状態です。対策としては、待たされている時間に応じて優先度を段階的に引き上げるエージング（優先度の動的な調整）が代表的です。
2.5.2デッドロックの発生条件と回避策
- デッドロックが発生するには、次の4条件が全て同時に満たされる必要があります。
①相互排他（資源は同時に1つのタスクしか使えない）／
②保持と待機（資源を確保したまま別の資源の空きを待つ）／
③非横取り（他タスクが確保した資源を強制的に奪えない）／
④循環待ち（複数タスクが環状に互いの資源を待ち合う）。逆に言えば、この4条件のうちどれか1つでも崩せばデッドロックは発生しません。 - 実務でのデッドロック回避策は、この4条件のどれを崩すかで整理できます。「全タスクが資源を確保する順序を統一する」のは循環待ち（
④）を崩す代表策で、常に資源1→資源2の順で確保すると決めておけば環状の待ち合いが構造的に起こりません。「一定時間確保できなければタイムアウトして確保済みの資源を解放しやり直す」のは保持と待機（
②）を崩す策です。「優先度の高いタスクが低いタスクの資源を強制的に横取りできるようにする」のは非横取り（
③）を崩す策ですが、横取りされたタスクの整合性維持が複雑になるという副作用があります。
「デッドロックの4条件＝相互排他・保持と待機・非横取り・循環待ち（全て揃うと発生）」「資源確保順序の統一＝循環待ちを崩す回避策」「SJFは理論上平均待ち時間最小だが長いジョブが飢餓状態になりうる」「エージング＝待ち時間に応じ優先度を引き上げ飢餓状態を防ぐ」が最頻出です。ミドルウェアの分類（DBMS・APサーバ・メッセージキュー）や、OSSライセンス（GPL＝改変時の再公開義務あり／MIT＝改変・再配布が緩やか）の違いも定番です。
デッドロックの4条件を、実際のシナリオに当てはめて検証してみましょう。あるオンラインバンキングシステムで、送金処理タスクAが「口座Xのロック」を確保した状態で「口座Yのロック」の空きを待ち、同時に別の送金処理タスクBが「口座Yのロック」を確保した状態で「口座Xのロック」の空きを待っているとします。このとき、
①相互排他（各口座ロックは1タスクしか保持できない）、
②保持と待機（両タスクとも一方のロックを保持したまま他方を待つ）、
③非横取り（相手が保持するロックを強制解除できない）、
④循環待ち（AはBの資源、BはAの資源を待つ環状構造）の4条件が全て揃っており、これはデッドロックです。この対策として最も実務的なのが、全ての送金処理タスクが「口座番号の小さい方から先にロックを取得する」という統一ルールを設けることです。このルールが徹底されれば、口座Xと口座Yのどちらの番号が小さくても、両タスクは必ず同じ順序でロックを試みるため、上記のような環状の待ち合い（循環待ち＝条件
④）が構造的に発生しなくなり、4条件のうち1つが崩れることでデッドロックが回避されます。ミドルウェアの役割にも触れておきます。ミドルウェアはOSとアプリケーションの中間に位置し、共通の機能を提供して開発の負担を減らすソフトウェアで、データの永続化を担うDBMS（データベース管理システム）、業務ロジックの実行環境を提供するAPサーバ、そしてシステム間で非同期にメッセージを受け渡すメッセージキュー（送信側と受信側の処理速度差を吸収し、片方が一時停止していても後で処理を継続できる）などがあります。OSSを利用する際は、ライセンスの違いにも注意が必要です。GPL（GNU General Public License）は、そのソフトウェアを改変して配布する場合、改変後のソースコードも同じGPLの下で公開する義務を課す（コピーレフト）一方、MIT Licenseは著作権表示を残せば改変・再配布・商用利用にほぼ制限がなく、自社製品への組み込みが容易です。この違いを理解せずにOSSを組み込むと、意図せず自社のソースコード公開義務を負ってしまうリスクがあります。
ひっかけ： 「デッドロックは相互排他・保持と待機・非横取りの3条件がそろえば発生する」は誤りです。循環待ち（
④）を含む4条件全てがそろって初めてデッドロックが発生します。3条件だけでは循環構造が無ければ発生しません。また「SJFは実行時間の長いタスクも短いタスクも公平に扱う」も誤り＝SJFは短いタスクを優先するため、長いタスクは後回しにされ続ける飢餓状態のリスクがあります。「MIT LicenseもGPLと同様、改変したソースコードの公開が義務付けられる」も誤り＝その義務（コピーレフト）を課すのはGPLで、MIT Licenseは著作権表示を残せば改変・再配布はほぼ自由です。
2.5.3この節のまとめ
- デッドロックの4条件＝相互排他・保持と待機・非横取り・循環待ち（全て揃って発生）。資源確保順序の統一＝循環待ちを崩す代表的回避策
- SJFは理論上待ち時間最小だが長いジョブが飢餓状態のリスク（エージングで緩和）。ミドルウェア＝DBMS/APサーバ/メッセージキュー
- GPL＝改変時の再公開義務（コピーレフト）。MIT License＝著作権表示を残せば改変・再配布がほぼ自由
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. デッドロックが発生するために必要な4条件のうち、「複数のタスクが環状に互いの資源の解放を待ち合っている」状態を指す条件はどれか。
Q2. 複数のタスクが資源を確保する際、常に資源番号の小さい方から先に確保するという統一ルールを設けることで防げるデッドロックの条件はどれか。
Q3. あるOSSライブラリを改変して自社製品に組み込み再配布する場合、改変後のソースコードも同じライセンスの下で公開する義務（コピーレフト）を課すライセンスはどれか。