| 両方とも前のリビジョン
前のリビジョン
次のリビジョン
|
前のリビジョン
|
book:operation_system_concepts [2020/06/04 10:38]
kijima |
— (現在) |
| ====== *Operation System Concepts ====== | |
| |
| <html> | |
| <a href="https://www.amazon.co.jp/Operating-System-Concepts-Abraham-Silberschatz/dp/1118093755/ref=as_li_ss_il?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=2NP8JH5CAVUWJ&keywords=operating+system+concepts&qid=1585662572&sprefix=operating+sys,aps,266&sr=8-1&linkCode=li1&tag=kijima05-22&linkId=d87adfa975fde5f679f98bf52f4886ba&language=ja_JP" target="_blank"><img border="0" src="//ws-fe.amazon-adsystem.com/widgets/q?_encoding=UTF8&ASIN=1118093755&Format=_SL110_&ID=AsinImage&MarketPlace=JP&ServiceVersion=20070822&WS=1&tag=kijima05-22&language=ja_JP" ></a><img src="https://ir-jp.amazon-adsystem.com/e/ir?t=kijima05-22&language=ja_JP&l=li1&o=9&a=1118093755" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" /> | |
| </html> | |
| ===== 概要 ===== | |
| |
| OSについての教科書。メジャーなOSそれぞれで用いられている技術が解説されている。実装方法や思想の違いはあるけれども、基本的な仕組みは共通している。ベースを学ぶ本。 | |
| |
| * プロセス管理 | |
| * メモリ管理 | |
| * ストレージ管理 | |
| * セキュリティ | |
| * 分散システム | |
| * 特別な目的のシステム | |
| |
| ===== 率直な感想:英語力が不足 ===== | |
| |
| 英語の習熟が不十分なのでよくわからないところが多い。文章はわかっても、全体として何が言いたいのか不明なときが多い。とはいえ300ページ時点で最初のときより、はるかにわかる。慣れてきた。 | |
| 章末にある問題は読むだけで、わからないものがほとんどであった。もっと考えよう。…ひどいものだが、それでも読みたいと思う。 | |
| |
| 何であれ自己満足に陥らないために大切なのは、テストだ…。章末問題は全然わからないし、後で何学んだかな？と思って書き出しても全然出てこない。ひどい。 | |
| |
| とはいえ、前もって知っていたところもあるので、全然わからないということはまれだ。全部サイアクというわけじゃない。本文は読むのが遅い。が、各章の序文は非常に読みやすくすっと理解できる。少なくとも前には進んでいることがわかる。 | |
| |
| ===== プロセス管理 ===== | |
| |
| * プロセス管理で必要なこと。マルチスレッド。スケジューリング。いくつかの戦略。長所と短所。 | |
| * プロセス、リソース、リクエスト。 | |
| * デッドロックしないように何が工夫されているか…防ぐ仕組み、検知する仕組み、復帰させる仕組み。各アルゴリズムの長所と短所。 | |
| * デッドロックが起こりうる条件。比喩→哲学者の食事、列。 | |
| ===== メモリ管理 ===== | |
| * プロセスごとに2つのレジスタ…物理アドレスの下限、上限があり、CPUは範囲内でしかアクセスできない。これによって誤、不正アクセスを防ぐ?(レジスタはCPUとセットで、プロセスごとにはないと思うが…。)、物理アドレスを動かすのは難しいが、仮想アドレスを動かすのはカンタン。動かしやすくする。物理アドレスは制約がたくさんある…。 | |
| * 実行するときに物理アドレスと再配置アドレスをリンクさせる？論理アドレス。 | |
| * CPUは論理アドレスを使い、メモリは物理アドレスを使う。変換を行うのがMMU。 | |
| * ユーザープログラムは物理アドレスを見ることがない。 | |
| * スタブでロードを再利用する | |
| * ロードするメモリを探す3つ戦略 | |
| * ページングの仕組み…図があるとわかった気になれる | |
| * 階層になったページテーブル。p1+p2+d→大分類→小分類→idみたいな感じか？セクション＋ページ＋オフセット。この構造、パケットに似ている。 | |
| * 分割しまくる。2nd outer page。 | |
| * 32bit以上だと分割も数が多すぎになる。hashを使う？ | |
| * 共有して省メモリ。データ部分だけ、ユーザプロセスにする。 | |
| ===== バーチャルメモリ管理 ===== | |
| * たくさんメモリを割り当てても、必ずしもパフォーマンス改善につながらない。アルゴリズムを正しく選択しないと。 | |
| * page-fault rateとframeの数をちょうどいい感じにする…CPUとメモリのバランスを最適化。(frameってなんだっけ。) | |
| * mapping | |
| * buddy system, slab allocatorがよくわからず | |
| * いろんなサイズのpageがある | |
| * データ構造によってlocalityに違いがある…スタックはよいlocality→一番上ばかり使われるから。一方ハッシュはわるいlocality→アクセスがバラバラだから。データ利用の効率の違いになる。 | |
| * オブジェクト指向はlocalityが低くなる傾向がある | |
| * I/Oとメモリ | |
| * バーチャルメモリは、サイズが大きな論理アドレスが、小さな物理メモリにマッピングすることを可能にするためにある。 | |
| * PageとPage Frameの関係 | |
| ===== ストレージ管理 ===== | |
| * fileは一般的形式で、ユーザーによって決められる…文字列、ソースコード、バイナリ… | |
| * OSが拡張子の対応方法を決めるのではなく、アプリケーションが決める。 | |
| * UNIXはファイルをシンプルなバイトの並びで定義している | |
| * 論理レコードが物理レコードの始まりを示す…？ | |
| * 論理レコードから物理ブロックへの変換？…ブロックとレコードの関係がよくわからない。 | |
| * ディスクスペースは物理ブロックに分配されている。ブロックの最後はたいてい捨てられる。→internal fragmentationに苦しめられる | |
| * シーケンシャルアクセス→順にアクセス…current pointer、next、rewindを使って、最も使われる。エディタやコンパイラはこの形式をよく使う。テープモデル。 | |
| * direct access→固定長の論理レコードを持つ。順番なし。ディスクモデル。 | |
| * indexファイルのindexを作る… | |
| * パーミッションとかの各システムによる違い | |
| |
| ===== ファイルシステム ===== | |
| * パーミッション、オーナー、タイムスタンプ、サイズ、…などのメタデータと、アドレス部分で構成されている。アドレスは辿っていく方式。メモリ管理の手法と同じで、ブロックで区切って穴を埋めていくことで、記憶空間を最大限使用できる。external fragmentationが必要ではない。ただし途中から読み込みができない。 | |
| |
| ↓しばらく飛んで | |
| |
| ===== システムレベルのセキュリティ ===== | |
| |
| パスワードなど。認証はむずい。パスワードはメジャーな方法だが、難しすぎるとメモして流失し，短すぎると総当りされる。ワンタイムパスワードなどもあるがメンドー。生体認証などがトレンドになっている。 | |
| |
| 侵入や不正な行動を検知するプログラムがある。本当にヤバい行為かをうまく判断することが必要。 | |
| たとえば多すぎても意味がなくなる。 | |