オペレーティングシステム 2014

1. http://www0.info.kanagawa-u.ac.jp/~kaiya/os/ オペレーティングシステム 2014 2014/6/5 木曜 2限 2年前期 海谷 治彦 永松 礼夫

2. 目次 • 演習の解答例 • 本日は先にアンケートフィードバック 9章 メモリの管理 • 9.1 メモリ資源 • 9.2 プログラム配置 • 9.3 プロセスのメモリ領域の管理 • 9.4 メモリ領域の確保・解放機能 • 9.5 メモリ領域割当アルゴリズム • 9.6 メモリに入らないプログラムの実行 時間があれば10章やるかも．

3. ファイルを分けないで！って書いてあるのに分けてある人ファイルを分けないで！って書いてあるのに分けてある人 4 名 涙

4. 前回の 本日の演習 • 今回紹介したサンプルプログラムの内，少なくとも一つを動作させてみよ． • 動作させた結果，理解できたこと，疑問に思ったこと等を述べよ． • どのサンプルを動かしたかも付記してね． • ちょっと改造した等の試行は歓迎します． • 加えて，前述の哲学者の問題において，どのようにデッドロックが起こるかも，わかった人は述べよ． • 別途，いつものアンケートもよろしくね．

5. 動作・観察法の例

6. fork1の見どころ • 基本，まずは，確かにプロセスが複製されていること，すなわち，a.out 等が二行あることを確認． • たしかに，プロセスID的に親子関係になっている． • 出力結果はわりとランダムである． • pcpcと常に規則正しいわけではない．

7. 動作・観察の例2

8. zombie.c につてい • これもプロセスの複数が起こっていることをpsコマンド等で確認． • そして，子のほうがゾンビ状態であることを，やはり，psコマンド等で確認． • 親プロセス側のelseブロックにてコメントアウトされている wait を有効にするとゾンビができないことを確認まですると優秀かも．

9. fork2 fork3 について • プログラム実行後，/bin/ls や /usr/bin/cal 等のコマンドを入力すると，たしかに，そのコマンドが実行され，当該プロセスIDが親側で表示されることを確認． • 親側でwaitするまえに10秒停止しているので，その間に ps コマンド等で観察すると，実行した /bin/ls 等がゾンビ状態になっているのが確認できるはず． • shellとしてさくさく動かすには，sleep(10)をコメントアウトする．

10. サンプル動作 C言語 • env.c execlp.c execls.c fp1.c は前回の話とあまり関係ないサンプルでした． • 特に最初の３つは「環境変数」という話題に関係するため，今回補足します． • 一応，2-101室のCentOSでコンパイルしましたが，警告はでるけど，コンパイルできないのは無かったような気がします． • (一応，警告を消したversion2をウエブページにはおいた) • fork1.cについて • 複製されたほうはcを表示し，複製元の親プロセスはpを表示するので，結果として p c の二種類の文字が画面に表示されます． • それぞれのプロセスが同期をとって順番に表示しているわけではないので，たまには pp と p が連続したり， cc と c が連続したりする場合もあります．

11. 環境変数 • プロセスは環境変数と呼ばれる変数名と値のペアを参照できます． • 広く知られる環境変数 • LANG アプリケーションが対応しているなら，この値に基づき YES/NO が はい/いいえ になったりします．calコマンドはコレに対応しています． • PWD ワーキングディレクトの場所がセットされています． • 通常，環境変数は親プロセスからコピーされますが，プロセス内で更新もできます． • プログラムからは getenv()関数や，グローバル変数 environ, main関数の第三引数等からアクセスできます． • main関数の第三引数はOSによっては提供していない場合があります．

12. LANGを変更した場合のcalの結果

13. 大工の例題 • 基本，デッドロックという現象を体感できればよいと思う． • プログラム内のコメントにも書いてあるが，一方の道具が無ければ他方を確保して待つというロジックになってるのがマズい．

14. 生産者消費者問題 • ここでの生産者消費者問題では，意図的に倉庫の上限を30個にしてある，そうしないと生産者がwaitされる機会が無くなるので． • 以下の二通りのことが起きるため，結果として，生産者，消費者ともに永久停止せず，たまに動く(生産したり消費したりする)ことが確認できればよい． • 生産過剰ケース • 倉庫が上限に達したら生産者がwaitになる． • 消費者が消費したら生産者にnotifyして，waitしている生産者をたたき起し，生産させる． • 消費過剰ケース (この例ではほとんど起きない) • 倉庫が空になったら消費者はwaitになる． • 生産者が生産したら消費者にnotifyして，waitしている生産者をたたき起し，消費させる．

15. 哲学者の問題 • 全員が自分の右側のホークをとって，左側が空くのを待つ． • もしくは，上記の逆． • 人間なら互いに譲り合えますが，プロセスは自発的にそんなことはできません．

16. アンケート: 授業一般 • 試験には簡単な計算問題がでるかも． • 他の授業の忙しいみたいですね．orz • 誤字が多くてすまん．指摘の時にはページ番号を指定してください． • 基本，試験は来週出す演習問題より優しい予定．

17. アンケート: ゾンビ • 通常，プロセスはゾンビ状態のままで長期間存在することは無く，親プロセスが明示的に終了させる必要があります． • また，親が終了すると子のゾンビも終了するので，実質，ゾンビだらけになることはほとんどありません． • 正直，ゾンビ状態の子プロセスを親が何に使っているのかはよくわかりませんが，下請け作業的なことを子プロセスに行わせた場合，異常終了した場合の，より詳しい調査等を親が行うために死んだプロセスの情報を残しておくのだと思っています． • ゾンビが増えると何か困るか？ということですが，一応，プロセスの情報はOSのデータセグメント内の変数として保持されているので，もう使ってない変数が増えるのは，やっぱり無駄なので，困るんでしょう．

18. アンケート: 干渉，デッドロック • 一般的なアプリケーションを開発する際には，干渉やデッドロックに注意する必要はありません． • しかし，OSを開発する場合や，(スレッド等を使い)並列で動く部分のあるプログラムの際には，干渉とデッドロックに注意する必要があるでしょう． • Windows系でアプリがフリーズする原因の一部にはデッドロックもかかわる場合がありますが，それだけではないと思います． • 基本，デッドロック回避のためには，空いてる資源をとりあえず押さえるを止めることでなんとかなると思います．

19. アンケート: プロセス生成 • プロセスのスケジュールや生成・消滅の手順はUNIX系，Win系で同じではないはずです． • 新しいプロセスを作る際に複製を作り中身を書きかえる明確な理由はわかりません． • おそらく，ゼロから新しいCS, DSを作りアドレス変換テーブルを作り・・・とするよりも楽だからでしょう． • プロセスは自分が終了したことを親プロセスには通知する(ただし親がwaitによって子からの連絡を待っている場合)． • 内部的には割り込みが利用されている．

20. アンケート: その他 • セマフォの考え方をプログラム言語(もしくはそれ風の説明文)内で表現しやすくしたのがモニタと思っています． • Linuxにおける init プロセスのコードはバージョンアップ毎に改良されているはずです．まぁ，init だけでなく全体にですが． • lphone (iphone?) でのムービー等を見るアプリの不具合は干渉とは関係ないでしょう． • Cの三項演算子について質問がありました value? exp1: exp2 ってヤツです． • 基本的には if(value) return exp1; else return exp2; という意味です．

21. 本日の話 • 9章の話はどちらかといえば古典的な話で，今時は10章にあるページ変換や仮想記憶で対処できてしまいます． • まぁ，しかし，一応，OSという授業のお約束として，話しておきます．

22. プログラムがメモリに読み込まれる． 計算に必要なメモリも確保される．（変数等のため) CPUがプログラムを順に読んで，計算をする． 必要ならば，デバイス(ファイル等)にアクセスする． メモリ 復習 プログラムの処理の流れ CPU プログラム 変数等 ファイル等

23. 復習 簡易な例題 ～ 二値の平均 CPU メモリ 100番地の数値を読め 101番地の数値を読め 4 数値を合計せよ 数値を2で割れ 102番地の数値を書け 5 100 101 102 3 4

24. 復習 実際の386CPUの構造 文献 p.57

25. 復習 参考: アドレスバス本数とメモリの広さ 216 = 65536 ≒ 65K 232 = 4294967296 ≒ 4G 264 = 18446744073709551616 ≒ 18E (エクサ) 32bitマシン主流の時代， 4G以上のメモリが無駄 といわれた所以は上記にある． 参考: バス本数が3本の場合 (23=8) 8個のアドレスしか 指定(区別)できない．

26. プロセスのためのメモリ • LinuxのCS, DSのところでも話したが， • プログラムを読み込む部分 • データを読み込む部分 の二種類は最低必要である． • データに関しては， • ヒープ: 動的に割り当てられるメモリのための領域． • スタック: 関数等が呼び出される毎に確保される領域． の二種類がある．

27. 以下の構成は現実的でない • PCでさえ昨今では常時100個近くのプロセスが動作する． • よって，左記のような割り当ては全く現実的ではない． • 4回目くらいに話したアドレス変換を用いるのが一般的． • でも，64bit空間なら割と現実的かも．

28. 復習 アドレス変換の考え方 2

29. ソースコードが実行できるまで • もしかしたら復習になるのかもしれないが，基本的な概念を概観する． • ソースコード 人間が手が書いたプログラムファイル． • オブジェクトコード 個々のソースコードを機械語に翻訳したファイル． • ロードモジュール 複数のオブジェクトコードを合体させてOSが実行可能な状態になったファイル．

30. Cというか一般的なUNIX, Linuxのバイナリ Cプログラムの開発の流れ プログラミング (手作業) コンパイル 実行 hoge.c a.out ソースコード (原始プログラム hoge.c等) ロードモジュール (実行可能プログラム a.out等)

31. 分割コンパイル プログラミング (手作業) コンパイル リンケージ ・エディット 実行 オブジェクトコード群 （目的ファイル， マシン語， hoge.o など) ソースコード群 (原始プログラム hoge.c 等) ロードモジュール (実行可能プログラム a.out 等)

32. 例 とある小さなエディタ 上記は，とても小さなテキストエディタのソースコード群だが， ファイル数で 58個， 総行数は 3万2千行ほどある．(.c .h のみ) Linuxはカーネルだけで1000万行を超えているらしい． Emacs-24.3は38万行以上，ファイルは360個 ( .c .h のみ)

33. リンケージ // a.c int foo(){ ..... } a.o コンパイル a.o から foo() をどう探す？ // b.c int bar(){ x=foo(); } b.o コンパイル b.o から bar() をどう探す？ // c.c main(){ x=bar(); } c.o コンパイル

34. ロードモジュールを読み込む レジスタ a.out ロード メモリ • ロードモジュールはどのように配置される？ • 配置後，計算過程においてレジスタ，メモリ等はどう変化する？

35. プログラムをメモリに配置する • 一般にプログラムのコンパイル時点では，ロードモジュールがメモリ内の，どこに配置されるかわからない． • アドレス変換が機能してるならアドレスを決め打ちしてもよい気もするけど． • よって，ロードモジュールのほうは，どこに配置されてもよいような構造である必要がある． • OSは，そのようなロードモジュールの中身をメモリ上に「上手く」配置する責務がある．

36. 再配置によるプログラムのロード • メモリ上のアドレス指定を未指定，もしくは相対指定にしてあるロードモジュールを，relocatable なロードモジュールと呼ぶ． • relocatable なモジュールは，通常，再配置レジスタ等を用いて，ある番地からの相対位置にプログラムを配置する． • 次頁の例．

37. 再配置レジスタを用いた例

38. ヒープとスタック • プロセスがデータのために利用する領域として以下の2種類がある． • ヒープ 動的に確保される変数等をおく場所． • スタック 関数呼び出しの際の引数，関数内のローカル変数等がおかれる． • 本来，スタックはもっと一般的な意味があるが，OSでは上記の意味で使う． • 上記それぞれは，実行前にどれだけの量必要かは予想できない．

39. ヒープを使うコードの例 #include <stdio.h> main(){ char buf[100]; char* ptr; while(fgets(buf,100, stdin)!=NULL){ if((ptr=(char*)calloc(1+strlen(buf), sizeof(char)))!=NULL){ strcpy(ptr, buf); printf("stored: %s\n", ptr); } } } ココでループ回る毎に入力された文字列を保存するための変数を動的に確保する． ループのまわる回数は事前予測不可能なため，確保されるメモリ量も予測不可能．

40. スタックの説明コードの例 #include <stdio.h> void char2hex(char* ptr){ char c; if(!*ptr) return; c=(*ptr); printf("%c = %x\n", c, c); char2hex(ptr+1); } main(int argc, char* argv[]){ char* ptr;int i; for(i=0; i<argc; i++){ printf(“%s\n”, argv[i]);char2hex(argv[i]); } } 関数内の変数 ptr と c が実際には各スタック内に保存される． この関数は再帰になっており，実際に何回繰り返し呼ばれるかは，引数の文字列の長さに依存する． 文字列は実行時に利用者から与えられるので，事前に長さを予測するのは不可能．

41. 前述例のスタックイメージ ptr: c: 未初期化 char2hex(“jindai”) を呼び出した場合， スタックの中身は 以下のようになる． 伝統的にスタックは， 下から上に伸ばすように書くが， メモリ上では上も下もないので， あまり関係ない． ptr: i c: i 関数呼び出しの順序 ptr: ai c: a ptr: dai c: d ptr: ndai c: n ptr: indai c: i ptr: jindai c: j

42. freeとGC • malloc, calloc 等の関数で動的に確保された領域(変数)は free 関数で明示的に開放することができる． • 一方，動的に確保された領域がプログラム内のどこからも参照されていない(ポインタで指されていない)ことは機械的に判断できる． • GC (Garbage Collection, ゴミ集め)は明示的な開放をプログラマが行わず，領域が参照されているか否かを判定し，自動的に領域解放を行う機能のことである． • 一般にリアルタイム処理(航空機制御等)では，GCを無効にするのが一般的．GC自体がシステム全体の処理を遅くするため．

43. メモリ領域割り当てアルゴリズム • 典型的なメモリ割り当てアルゴリズムを紹介してゆく． • ファイルシステムの管理に雰囲気がちょっと似ているが， • ファイルの場合 長い時間のスパン (電源切っても消えない) • メモリの場合，プロセスの寿命程度 (lsなら一瞬，しかし，長時間動いているものもある) という違いがある．

44. メモリの空き領域の管理 • ビットマップ式 • 使ってる/使ってないを0/1の情報でデータとして管理． • リスト式 • 空いてる場所をリスト構造で管理． • どっちにしろ，一つの番地毎(1バイト毎)に管理していては，やってられないので，次章のページ管理が必須．

45. 割り当てアルゴリズム • First fit • 最初に発見された空き領域を利用 • Best fit • 必要サイズにぴったり合う空き領域を利用 • Worst fit • 大きい空き領域から使う orz

46. 断片化 • ディスク同様，メモリの場合も断片化が起こりうる． • 対策として以下の2種類がある． • メモリの詰め直し • 再配置可能なプログラム(前述)でないと対応できない． • オーバーヘッドが大きい． • ページング • ページ変換テーブルを最適化することで，断片化を解消することができる．

47. メモリに入りきらないプログラム？ • 現代の32bit, 64bitアーキテクチャでは，論理的にはメモリに入らないプログラムはほとんどない．(それぞれ4G, 18Eの広さがあるため) • しかし，実メモリは4G未満かもしれなので，入らないことがあるかもしれない． • 現代では10章の仮想記憶を使い，たとえ2Gしか実メモリがなくても，4Gあるように見せかけることが可能． • 以降のオーバーレイ，スワッピングは上記のような技術が広まる以前の発想である．

48. オーバーレイ • 常時メモリに配置する必要の無い部分同士で，メモリ領域を共有する方式． • そのような領域をオーバーレイセグメントと呼ぶ． • 当然，ある一瞬にはオーバーレイセグメント群のうちの一つのみがメモリを利用できる．

49. オーバーレイのイメージ

50. スワッピング 1/2 物理メモリが満杯の場合， 新しいプロセスは当然生成できません．