オペレーティング システムの概要

おい、ハブル！ 私の意見では、興味深い文献の XNUMX つである OSTEP の翻訳シリーズの記事を紹介したいと思います。 この資料では、UNIX に似たオペレーティング システムの動作、つまり、最新の OS を構成するプロセス、さまざまなスケジューラ、メモリ、およびその他の同様のコンポーネントの動作について非常に詳しく説明します。 すべての資料のオリジナルはこちらからご覧いただけます ここで。 翻訳は専門的ではなく（まったく自由に）行われたことに注意してください。しかし、一般的な意味を保持していれば幸いです。

このテーマに関するラボの作業は、次の場所にあります。

• オリジナル： Pages.cs.wisc.edu/~remzi/OSTEP/宿題/宿題.html
• オリジナル： github.com/remzi-arpacidusseau/ostep-code
• 私の個人的な適応： github.com/bykvaadm/OS/tree/master/ostep

その他の部品

• パート 1: イントロダクション

私のチャンネルもチェックできます 電報 =)

OS がユーザーに提供する最も基本的な抽象概念であるプロセスを見てみましょう。 プロセスの定義は非常に単純です。 実行中のプログラム。 プログラム自体はディスク上に存在する生命のないものであり、一連の命令と、場合によっては起動を待っているいくつかの静的データです。 これらのバイトを取得して実行し、プログラムを有用なものに変換するのは OS です。
ほとんどの場合、ユーザーは複数のプログラムを同時に実行したいと考えます。たとえば、ラップトップ上でブラウザ、ゲーム、メディア プレーヤー、テキスト エディタなどを実行できます。 実際、一般的なシステムでは、数十または数百のプロセスを同時に実行できます。 このため、システムは使いやすくなり、CPU が空いているかどうかを気にする必要がなく、プログラムを実行するだけで済みます。

これにより、多くの CPU の錯覚をどのように提供するかという問題が生じます。 物理的な CPU が XNUMX つしかない場合でも、OS はどのようにしてほぼ無限の数の CPU があるかのような錯覚を作り出すことができるのでしょうか?

OS は CPU 仮想化を通じてこの錯覚を作り出します。 XNUMX つのプロセスを開始し、それを停止し、別のプロセスを開始するなどすることで、実際には XNUMX つ以上の物理プロセッサがあるにもかかわらず、OS は多数の仮想 CPU があるという錯覚を維持できます。 このテクニックはと呼ばれます CPUリソースを時間で割ったもの。 この技術を使用すると、ユーザーは必要な数だけ同時プロセスを実行できます。 このソリューションのコストはパフォーマンスです。CPU が複数のプロセスで共有される場合、各プロセスの処理が遅くなるからです。
CPU 仮想化を実装するには、特にそれを適切に実行するには、OS に低レベルと高レベルの両方のサポートが必要です。 低レベルのサポートと呼ばれます メカニズム 機能の必要な部分を実装する低レベルのメソッドまたはプロトコルです。 このような機能の例としては、コンテキスト スイッチングが挙げられます。これにより、OS はプロセッサ上で XNUMX つのプログラムを停止し、別のプログラムを実行できるようになります。 この時間分割は、最新のすべてのオペレーティング システムに実装されています。
これらのメカニズムの上に、「ポリシー」の形で OS に組み込まれたロジックがいくつかあります。 ポリシー オペレーティング システムの特定の意思決定アルゴリズムです。 たとえば、このようなポリシーは、(コマンドのリストから) 最初に起動するプログラムを決定します。 したがって、たとえば、この問題は次のような政策によって解決されます。 スケジューラ (スケジュールポリシー) そして、ソリューションを選択する際には、起動履歴 (過去数分間に最も長く起動されたプログラム)、このプロセスにかかる負荷 (起動されたプログラムの種類)、パフォーマンス指標 (システムがインタラクティブな対話やスループットなどに最適化されています。

抽象化：プロセス

オペレーティング システムによって実行される実行プログラムの抽象化を、私たちがそう呼んでいます。 プロセス。 前述したように、プロセスは、任意の瞬間に実行されている単なるプログラムです。 このプログラムが実行中にアクセスまたは影響を与えるさまざまなシステム リソースから概要情報を取得できるプログラム。
プロセスのコンポーネントを理解するには、システムの状態、つまりプログラムが動作中に何を読み取り、変更できるかを理解する必要があります。 いつでも、システムのどの要素がプログラムの実行にとって重要であるかを理解する必要があります。
プロセスに含まれるシステム状態の明白な要素の XNUMX つは次のとおりです。 記憶。 命令はメモリ内にあります。 プログラムが読み書きするデータもメモリ内に配置されます。 したがって、プロセスがアドレス指定できるメモリ (アドレス空間と呼ばれる) はプロセスの一部です。
レジスタもシステム状態の一部です。 多くの命令はレジスタの値を変更したり、その値を読み取ったりすることを目的としているため、レジスタもプロセスの動作の重要な部分になります。
マシン状態はいくつかの特殊レジスタからも形成されることに注意してください。 例えば、 IP - 命令ポインタ — プログラムが現在実行している命令へのポインタ。 もあります スタックポインタ そしてそれに関連する フレームポインタ、関数パラメータ、ローカル変数、戻りアドレスを管理するために使用されます。
最後に、プログラムは ROM (読み取り専用メモリ) にアクセスすることがよくあります。 この「I/O」(入力/出力) 情報には、プロセスによって現在開かれているファイルのリストが含まれている必要があります。

プロセスAPI

プロセスがどのように機能するかについての理解を深めるために、オペレーティング システム インターフェイスに含める必要があるシステム コールの例を検討してみましょう。 これらの API は、どの OS でも何らかの形式で利用できます。

● 創造する (作成): OS には、新しいプロセスを作成できる何らかのメソッドが含まれている必要があります。 ターミナルにコマンドを入力するか、アイコンをダブルクリックしてアプリケーションを起動すると、OS に呼び出しが送信され、新しいプロセスが作成され、指定されたプログラムが起動されます。
● 削除: プロセスを作成するためのインターフェイスがあるため、OS はプロセスを強制的に削除する機能も提供する必要があります。 ほとんどのプログラムは、実行中に自然に開始および終了します。 それ以外の場合、ユーザーはそれらを強制終了できるようにしたいので、プロセスを停止するインターフェイスが役立つでしょう。
● 待つ (待機中): プロセスが完了するまで待機すると便利な場合があるため、待機機能を提供するインターフェイスがいくつか提供されています。
● その他の制御 (各種制御): プロセスを強制終了して待機する以外にも、さまざまな制御方法があります。 たとえば、ほとんどのオペレーティング システムには、プロセスをフリーズ (一定期間実行を停止) してから再開 (実行を継続) する機能が備わっています。
● Status: (状態): プロセスの実行時間や現在の状態など、プロセスのステータスに関する情報を取得するためのさまざまなインターフェイスがあります。

プロセスの作成: 詳細

興味深い点の XNUMX つは、プログラムがどのように正確にプロセスに変換されるかということです。 特に、OS がプログラムをどのように取得して実行するかが重要です。 プロセスがどの程度正確に作成されるか。
まず、OS はプログラム コードと静的データをメモリ (プロセス アドレス空間) にロードする必要があります。 プログラムは通常、何らかの実行可能形式でディスクまたはソリッド ステート ドライブに保存されます。 したがって、プログラムと静的データをメモリにロードするプロセスでは、OS がディスクからそれらのバイトを読み取り、メモリのどこかに配置できる必要があります。

初期のオペレーティング システムでは、ロード プロセスが熱心に実行されました。これは、プログラムが起動される前にコード全体がメモリにロードされることを意味します。 最新のオペレーティング システムはこれを遅延的に実行します。つまり、プログラムの実行中にコードまたはデータが必要な場合にのみコードまたはデータを読み込みます。

コードと静的データが OS メモリにロードされたら、プロセスを実行する前に行う必要があることがさらにいくつかあります。 ある程度の量のメモリをスタックに割り当てる必要があります。 プログラムは、ローカル変数、関数パラメータ、戻りアドレスにスタックを使用します。。 OS はこのメモリを割り当ててプロセスに与えます。 スタックには、いくつかの引数を割り当てることもできます。具体的には、main() 関数のパラメータを、たとえば argc と argv の配列で埋めます。

オペレーティング システムは、一部のメモリをプログラム ヒープに割り当てることもあります。 ヒープは、動的に割り当てられたデータを明示的に要求するためにプログラムによって使用されます。。 プログラムは関数を呼び出してこのスペースを要求します。 malloc（） 関数を呼び出して明示的にクリアします 自由（）。 ヒープは、リンクされたシート、ハッシュ テーブル、ツリーなどのデータ構造に必要です。 最初は少量のメモリがヒープに割り当てられますが、プログラムが実行されるにつれて、ヒープはライブラリ API 呼び出し malloc() を通じてより多くのメモリを要求することができます。 オペレーティング システムは、これらの呼び出しを満たすために、より多くのメモリを割り当てるプロセスに関与します。

オペレーティング システムは、初期化タスク、特に I/O に関連するタスクも実行します。 たとえば、UNIX システムでは、デフォルトで各プロセスに、標準入力、出力、エラー用に 3 つのオープン ファイル記述子があります。 これらのハンドルを使用すると、プログラムは端末からの入力を読み取り、画面に情報を表示できるようになります。

したがって、コードと静的データをメモリにロードし、スタックを作成および初期化し、I/O タスクの実行に関連するその他の作業を行うことにより、OS はプロセスを実行するための準備を整えます。 最後に、最後のタスクが XNUMX つ残っています。それは、main() 関数と呼ばれるエントリ ポイントを通じてプログラムを実行することです。 main() 関数を実行すると、OS は新しく作成されたプロセスに CPU 制御を移し、プログラムの実行が開始されます。

プロセス状態

プロセスとは何か、そしてプロセスがどのように作成されるかをある程度理解したところで、プロセスが取り得るプロセスの状態をリストしてみましょう。 最も単純な形式では、プロセスは次のいずれかの状態になります。
● Running:。 実行中、プロセスはプロセッサ上で実行されます。 これは命令が実行されていることを意味します。
● レディ。 準備完了状態では、プロセスを実行する準備ができていますが、何らかの理由で OS は指定された時間にプロセスを実行しません。
● ブロックされました。 ブロックされた状態では、プロセスは、何らかのイベントが発生するまで実行準備が整わないようにするいくつかの操作を実行します。 一般的な例の XNUMX つは、プロセスが IO 操作を開始するとブロックされ、他のプロセスがそのプロセッサーを使用できるようになります。

これらの状態をグラフの形で想像することができます。 図からわかるように、プロセスの状態は OS の裁量によって RUNNING と READY の間で変化します。 プロセスの状態が READY から RUNNING に変わると、プロセスがスケジュールされたことを意味します。 反対方向 - レイアウトから削除されます。 たとえば、IO 操作を開始するなど、プロセスがブロック状態になった瞬間、OS は、IO の完了などの何らかのイベントが発生するまでプロセスをこの状態に保ちます。 この時点で READY 状態に移行し、OS が判断した場合はすぐに RUNNING 状態に移行する可能性があります。
XNUMX つのプロセスがこれらの状態をどのように通過するかの例を見てみましょう。 まず、両方のプロセスが実行中で、それぞれが CPU のみを使用していると想像してみましょう。 この場合、状態は次のようになります。

次の例では、最初のプロセスは、しばらく実行した後、IO を要求して BLOCKED 状態に入り、別のプロセスの実行を許可します (図 1.4)。 OS はプロセス 0 が CPU を使用していないことを確認し、プロセス 1 を開始します。プロセス 1 の実行中に IO が完了し、プロセス 0 のステータスが READY に変わります。 最後に、プロセス 1 が完了し、完了するとプロセス 0 が開始、実行され、作業が終了します。

データ構造

OS 自体はプログラムであり、他のプログラムと同様に、さまざまな関連情報を追跡するいくつかの重要なデータ構造を持っています。 各プロセスの状態を追跡するために、OS はいくつかの機能をサポートします。 プロセスリスト READY 状態のすべてのプロセスと、現在実行中のプロセスを追跡するための追加情報。 また、OS はブロックされたプロセスを監視する必要があります。 IO が完了したら、OS は必要なプロセスを起動し、実行可能な状態にする必要があります。

たとえば、OS はプロセッサ レジスタの状態を保存する必要があります。 プロセスが停止した瞬間にレジスタの状態がプロセスのアドレス空間に保存され、動作が継続した瞬間にレジスタの値が復元され、このプロセスの実行が継続されます。

準備完了、ブロック済み、実行中の状態に加えて、その他の状態もあります。 場合によっては、プロセスの作成時にプロセスが INIT 状態になることがあります。 最後に、プロセスはすでに完了しているが、その情報はまだクリアされていない場合、プロセスを FINAL 状態にすることができます。 UNIX システムでは、この状態は次のように呼ばれます。 ゾンビプロセス。 この状態は、親プロセスが子の戻りコードを知りたい場合に役立ちます。たとえば、通常は 0 は成功を示し、1 はエラーを示しますが、プログラマは追加の出力コードを発行して別の問題を知らせることができます。 親プロセスが終了すると、wait() などの最終システム コールを実行して子プロセスが終了するのを待ち、終了したプロセスに関連付けられたデータをクリアできることを OS に通知します。

講義の要点:

● プロセス — OS 内で実行中のプログラムの主な抽象化。 いつでも、プロセスはその状態、つまりアドレス空間内のメモリの内容、命令ポインタやスタック ポインタを含むプロセッサ レジスタの内容、読み書きされるオープン ファイルなどの IO 情報によって説明できます。
● プロセスAPI プログラムがプロセスに対して実行できる呼び出しで構成されます。 通常、これらは作成、削除、またはその他の呼び出しです。
● プロセスは、実行中、準備完了、ブロック化などのさまざまな状態のいずれかにあります。 スケジューリング、スケジューリングからの例外、待機などのさまざまなイベントにより、プロセスの状態が別の状態に変化する可能性があります。
● プロセスリスト システム内のすべてのプロセスに関する情報が含まれています。 その中の各エントリはプロセス制御ブロックと呼ばれ、実際には特定のプロセスに関する必要な情報がすべて含まれる構造です。 

出所： habr.com