OS Design and Impl ch2

Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

OPERATING SYSTEMSDESIGN AND IMPLEMENTATION

Third EditionANDREW S. TANENBAUMALBERT S. WOODHULL

Chapter 2Processes

presented byYohei Yasukawa


Outline2.1 プロセス概論

– プロセスモデル, プロセスの生成/終了,プロセスの階層, 状態, 実装

2.2 プロセス間通信– 競合状態, クリティカルセクション,

ビジーウェイトによる相互排除,スリープ/ウェイクアップ, セマフォ, ミューテックスモニタ, メッセージパッシング

2.3 IPCの古典的問題– 哲学者の食卓問題, リーダライタ問題








2.1 プロセス概論

– マルチプログラミングシステム• プロセスを次々と切り替えて処理するシステム

– CPUは数十〜数百ミリ毎に処理を切り替える– どの瞬間も、CPUはただ1つのプログラムを実行– 1秒間に複数のプログラムを実行(擬似並列処理)


2.1.1 プロセスモデル

– 多数の逐次プロセスで構成されているという見方• “プロセスは仮想CPUを占有して持っている”と捉える

コンピュータから見た

マルチプログラム処理

人間から見た

マルチプログラム処理


2.1.1 プロセスモデル– プロセスに関する留意点

• 実時間の要求があるプロセス– Ex. 磁気テープ装置を制御するI/O処理

• プロセスの切り替え方– プロセス：活動

» プログラム, 入出力, 状態を持つ– プログラム：本, レシピ

» プロセスがプログラムを読みながら処理を実行– Ex. レシピを見てケーキを焼いている途中に、

　蜂に刺された息子が泣きながら駆け込んできた。


2.1.2 プロセスの生成– プロセスには四つの主要な事象が存在

1. システムの初期化2. 実行中のプロセスによるプロセス生成

– Ex. makeプログラムによるコンパイル時

3. ユーザからの新たなプロセス生成の要求– Ex. 対話システムにおけるプロセスの生成

4. バッチジョブの開始– Ex. 大規模なメインフレームのバッチシステム


2.1.3 プロセスの終了– プロセスは以下のいずれかの条件によって終了• Normal exit (voluntary)

– なすべき仕事を完了した場合

• Error exit (voluntary)– 致命的なエラーを検出した場合

• Fatal Error (involuntary)– プログラムのバグ等によるエラーが発生した場合

Ex. 存在しないメモリの参照, ゼロ除算

• Killed by another process (involuntary)


2.1.4 プロセス階層– 親プロセスと子プロセスは1対多の関係– MINIX 3におけるプロセス階層の用例：

• キーボードからのシグナル受信– 受信 or 無視 or キルされる

• RS, initスレッドを用いた自身の初期化– Reincarnation Serverスレッド：

ドライバおよびサーバの起動, 再起動を行う– Initスレッド：

Rsに指令を発行して、ドライバとサーバの起動を行う– Ex. ドライバがクラッシュしたときの自動回復

» 1. RSの子プロセスとしてドライバ起動» 2. ドライバ終了した時、通知される» 3. 通知が来たら再起動


2.1.5 プロセスの状態

– プロセス同士の通信や同期をするとき、状態の情報が必要になる。Ex. “cat hoge1 hoge2 hoge3 | grep foo”

– プロセスが取りうる3つの状態1. Running

– その瞬間CPUを実際に使っている

2. Ready– 実行可能だが、他プロセスが実行中のため一時停止

3. Blocked– 何らかの外部的事象が発生しない限り実行できない



Figure 2-2 プロセスの状態遷移図



Figure 2-3 プロセス構造をとるOSでは、OSの最下層が割り込みとスケジューリングを処理する。

　その上部に、逐次プロセスが存在する。


2.1.6 プロセスの実装

– プロセスモデルの実現• プロセステーブルの作成

– プロセス単位で確保するエントリーテーブル– Ex. PC, SP, メモリ割当て情報など

– スケジューラの実現(→2.4章で詳しく説明)• 割込みディスクリプタテーブルの作成• 割込みベクタ• 割込みサービス手続き


2.1.7 スレッド

– プロセスとスレッドの違い• プロセス：独自のアドレス空間における制御の流れ

– 関連する資源がまとめられ、管理が簡単。

• スレッド：同一アドレス空間内における制御の流れ– CPUでプログラム実行をスケジュールされる実態


2.1.7 スレッド

– スレッドの管理方法• ユーザ空間で管理

– スレッドの切り替えを速くするため

• カーネル空間でもスレッドを認識– プロセス全体のブロックを避けるため


2.1.7 スレッド

– スレッドの問題• プロセスの複製

– Ex. キーボード入力の受信

• データの複製– Ex. ファイル読み込み中にクローズ

• エラーの報告– Ex. errnoを読み出す前にシステムコールを実行

– 解決不可能ではないが、システムの再設計が困難• Ex. システムコール, ライブラリの書き直し








2.2 プロセス間通信

– プロセス間通信における3つの問題1. 情報の伝達2. 互いの処理を妨害しない• 正しい実行順序の決定

– cf. スレッド間通信における問題との相違1. 簡単に解決2. プロセスと同じ解決方法3. プロセスと同じ解決方法


2.2.1 競合状態

– 競合状態：　2つ以上のプロセスが共有データを読み書きし、　その順序によって最終結果が異なるような状況。


2.2.2 クリティカルセクション

– 競合状態の発生を避けるため、相互排除したい。• クリティカルセクション(危険領域)に注意する。


2.2.2 クリティカルセクション

– よい解決方法を得るための4つの条件1. 同時に危険領域に入らない。• 処理速度またはCPUの個数に関する仮定をおかない。• 危険領域以外を実行中のプロセスは

他のプロセスをブロックしない。• プロセスは危険領域に入るために無期限に待たない。


2.2.3 ビジーウェイトによる相互排除

– 相互排除を実現する方法のいくつかを紹介。• 割込み禁止方式• ロック変数方式• 厳密な相互実行方式

– ビジーウェイトを使った解決法

Process 0 Process 1



– 相互排除を実現する方法のいくつかを紹介。• Petersonの解決方式

– 関数enter_regionと関数leave_regionを使った相互排除



– 相互排除を実現する方法のいくつかを紹介。• Petersonの解決方式

– 関数enter_regionと関数leave_regionを使った相互排除



– 相互排除を実現する方法のいくつかを紹介。• TSL命令

– ハードウェアを使った相互排除


2.2.4 スリープとウェイクアップ

– CPU時間を消費せずに処理を停止させるプロセス間通信• Sleep: 呼出元のプロセスを停止する• Wakeup: 引数に指定したプロセスを起こす

– 用例：生産者消費者問題• 2つのプロセスが共通の固定長バッファを共有• 生産者は情報を入力し、消費者は情報を取り出す

– 問題：バッファが空の場合の、消費者の振る舞い– 解決策：消費者は、生産者が情報を入力するまでsleep


2.2.4 スリープとウェイクアップ

プロセスA プロセスB

競合状態が起こる？起こらない？


2.2.5 セマフォ

– セマフォ：受け取ったウェイクアップ合図を正数変数に保存し、後で使用する。• Down操作：値が0より大きいか検査し、大きければ1減らす。値が0であれば、down操作を完了させずにスリープ。

• Up操作：値を1増やし、down操作でスリープしているプロセスがあれば起こす。

• 上述の操作はいずれもアトミックアクションとして処理される


2.2.5 セマフォ

– セマフォを用いた生産者消費者問題の解決法• セマフォの検査, 更新, およびスリープを発行する間は全ての割込みを禁止

• 3つのセマフォを利用– Full: 使用中のスロット数

初期値は0, 同期処理のために用いる。– Empty: 空きスロット数

初期値はバッファにあるスロット数, 同期処理のために用いる– Mutex: ロックの状態を表す変数

初期値は1, 相互排除のために用いる


2.2.5 セマフォ


2.2.6 ミューテックス

– ロックされているか、されていないかの状態を取る変数• セマフォの値を数える必要がない場合に用いる。

– mutexに対する2つの手続き• mutex_lock:危険領域にアクセスするときに呼び出す。

• mutex_unlock:危険領域での作業が完了した時に呼び出す。


2.2.7 モニタ

– セマフォよりも簡単に正しいプログラムを書ける。• モニタ：高水準の同期のためのプリミティブ

– 相互排除をコンパイラで実現– プロセスの停止 / 再生の手続き

» Wait: 状態変数を引数に指定して呼び出す。呼出元のプロセスはブロックされる。

» Signal: 状態変数を引数に指定して呼び出す。　該当するプロセスをウェイクアップする。


2.2.7 モニタ


2.2.7 モニタ


2.2.7 モニタ

– モニタおよびセマフォが抱えている問題• 共有メモリにアクセス可能な1つ以上のCPUを備える環境に置いて相互排除の問題を解決するために設計– それぞれ独立した固有メモリを持つ、

複数のCPUからなる分散システムには適用できない。


2.2.8 メッセージパッシング

– SendとReceiveの2つの基本構造を用いたプロセス間通信• Send: 指定された送付先に対してメッセージを送信• Receive: 送信元から送られるメッセージを受信

– 設計上の問題• ネットワークにおいてメッセージを見失った場合

– 受信者からの受領確認メッセージ

• 受領確認メッセージを見失った場合– 各メッセージに通し番号を振る

• パフォーマンスの問題– Ex. メッセージの大きさをマシンのレジスタのサイズに制限

レジスタを介してメッセージパッシングを行う



– メッセージパッシングによる生産者消費者問題• Mail-box: 指定した数のメッセージを貯める場所

– Send, Receiveの引数にメールボックスの住所を指定

• Cf. Rendezvous方式– 中間でのバッファリングを行わず、直接メッセージをコピー– Receive前にsendが発行された場合、

Receiveが発行されるまでブロックされる










2.3 IPCの古典的問題

– プロセス間通信においてよく知られている2つの問題1. 哲学者の食卓問題2. リーダライタ問題


2.3.1 哲学者の食卓問題

　　　1965年にDijkstraによって考案された同期問題

　　　　　　ルール• 左右のフォークを

取ろうとする2. 成功すると食事• フォークを置き,思考を続ける

皆が同時にフォークを取ろうとする場合– デッドロック, 飢餓状態



Figure 2-19. A non-solution to the dining philosophers problem.



Figure 2-20. A solution to the dining philosophers problem.

. . .




. . .

. . .




. . .


2.3.2 リーダライタ問題

– データベースへのアクセスをモデル化した問題– 用例：航空券の予約システム

• 多数の競合するプロセスが読み書きを行う。• 多数が同時にデータベースを読むことは容認。• あるプロセスがデータベースを更新している場合は

その他のプロセスによるアクセスは全て許されない。



Figure 2-21. A solution to the readers and writers problem. . . .



Figure 2-21. A solution to the readers and writers problem.

. . .


Summary2.1 プロセス概論






参考資料

– Spin• 大学院講義科目高信頼ソフトウェア

– http://www.ueda.info.waseda.ac.jp/oess/RS2008/

• What is Spin? - Spin公式サイト– http://spinroot.com/spin/whatispin.html

• Spin Online References - Spin公式サイト– http://spinroot.com/spin/Man/

http://www.ueda.info.waseda.ac.jp/oess/RS2008/

http://spinroot.com/spin/whatispin.html

http://spinroot.com/spin/Man/


OPERATING SYSTEMSDESIGN AND IMPLEMENTATION

Third EditionANDREW S. TANENBAUMALBERT S. WOODHULL

Chapter 2Processes

presented byYohei Yasukawa

2009/04/30




















お詫びと訂正

– ビジーウェイトによる相互排除• 割込み禁止方式• ロック変数方式• 厳密な相互実行方式• Petersonの解決方式• TSL命令

– 上述の方式は全てビジーウェイトによる相互排除• CPU時間を浪費するので、避けるべき








2.2.5 セマフォ(復習)

– セマフォ：受け取ったウェイクアップ合図を正数変数に保存し、後で使用する。• Down操作：

値が0より大きいか検査し、大きければ1減らす。値が0であれば、down操作を完了させずにスリープ。

• Up操作：値を1増やし、down操作でスリープしているプロセスがあれば起こす。

• 上述の操作はいずれもアトミックアクションとして処理される


2.2.5 セマフォ

– セマフォを2通りの用いる方法

1. 同期用のセマフォ– 汎用セマフォ

»

2. 相互排除用のセマフォ– バイナリセマフォ

» Mutex

•








2.3 IPCの古典的問題

– プロセス間通信においてよく知られている2つの問題

1. 哲学者の食卓問題

2. リーダライタ問題



　　　1965年にDijkstraによって考案された同期問題

　　　　　　ルール1. 思考している

2. 左右のフォークを取ろうとする

3. 成功すると食事

4. フォークを置き,再び思考を始める

皆が同時にフォークを取ろうとする場合– デッドロック, 飢餓状態



– データベースへのアクセスをモデル化した問題– 用例：航空券の予約システム

• 多数の競合するプロセスが読み書きを行う。• 多数が同時にデータベースを読むことは容認。• あるプロセスがデータベースを更新している場合は

その他のプロセスによるアクセスは全て許されない。


Summary2.1 プロセス概論







– SendとReceiveの2つの基本構造を用いたプロセス間通信• Send: 指定された送付先に対してメッセージを送信• Receive: 送信元から送られるメッセージを受信

– 設計上の問題• メッセージを見失った場合

– 受信者からの受領確認メッセージ

• 受領確認メッセージを見失った場合– 各メッセージに通し番号を振る

• 認証の問題– 通信相手が本物かどうか

• パフォーマンスの問題– 送信者と受信者が同じマシンの場合



– メッセージパッシングによる生産者消費者問題• Mail-box: 指定した数のメッセージを貯める場所

– Send, Receiveの引数にメールボックスの住所を指定

• Cf. Rendezvous方式– 中間でのバッファリングを行わず、直接メッセージをコピー

– Receive前にsendが発行された場合、Receiveが発行されるまでブロックされる



OS Design and Impl ch2

Documents