多くのプロセスがあり、リソースは限られています。 一度に十分ではありません。 どうする？ そして、ここではキューイングシステムとの類似性があります。 プロセスのプールは、キャッシュデスクのキューとして想像できます。 申し訳ありませんが、プロセッサに。 そして、そのようなキューには3つの古風な処理オプションがあります。
まえがき
最初は、プロセッサが1つしかないという事実に焦点を当てます。 簡素化する。 それから、私の意見では、違いは何ですか。
開始するには：一般情報。
CPUの画像
「プロセス」とは何ですか？「ストリーム」との違いは何ですか？ プロセスは（大まかに）何かを実装するための要求です。 より正確には、システムリソースの消費。 OSは、このプロセスに必要なリソースを示すシステム情報を生成します。 また、実際に彼に割り当てられたリソースについても。 これは、新しく作成されたプロセスごとに個別に行われます。 必要なメモリ量、プロセッサ時間などについて。
それで、私は何について話しているのですか？ そうそう。
プロセスキューを処理する方法について
先ほど言ったように、キューを処理する3つの古風な方法を知っています。
最初：量子化。
つまり、特定のタイムスライスが各プロセスに割り当てられ、その後、プロセッサは「無料のキャッシュデスク！」と喜んで報告し、次のサービスプロセスを受け取ります。 現在のプロセスはキューの最後に移動します。 「すべて等しい」。 欠点：（失礼な例）ビデオ会議を行っています。 とても重要です。 最も興味深い場所：ブロード！ そして、「重要な」ドキュメントの印刷が開始されます。 彼は、毎日の昼食の配達時間を13:00から14:00に延期するよう求める手紙です。 そして、あなたのビデオ会議「いつそれは知られていない」が再開されます。 もちろん、実際にはこれは起こりません。なぜなら、プリンターは中断によって動作し、そこではすべてが異なるからです。 しかし、私にとっては、その類推は一般的に明らかです。
第二：優先事項。
これは「誰もが平等ではない」ときです。 プロセスには優先順位が割り当てられ、より高い優先順位のプロセスが処理される（oh、sorry、processed）まで、他のプロセスはチェックアウト（oh、sorry、processor）できません。 短所：優先度が低いため、まったく処理されないプロセスが存在する場合があります。 つまり、レターを印刷することはありません。
実際には、「すべて等しいが、一部はより等しい」というアプローチがよく使用されます。 つまり、「混合」です。 プロセスに時間のクォンタムと優先度が同時に割り当てられる場合。 その後、プロセスはキューの最後ではなく、中間の「その」場所に移動します。 そしてそこで彼は待っています。
図は明確ですが、プロセスはどのように処理されますか？ 何の順番で？ それでも同じキューイングシステムです。 量子化と「混合」タイプの場合、プロセスを処理する方法はいくつかあります。
-FIFO。 先着順です。 （先入れ先出し）
-LIFO。 最後のものが来て、最初のものが出てきました。 （私見、あまり正直ではない...）（後入れ先出し）
-シロ。 まあ、それは完全にランダムです。 サービスインランダムアウト。
「純粋な」優先順位の場合、もちろんそのような疑問は生じません。
また、マルチプロセッサシステムについてはどうですか？
結局のところ、私はこの主題に関する私の考えを共有することを約束しました。 さて、いくつかのキャッシュレジスタ（プロセッサ）があることを想像してみましょう。 そして、ここでは同じ原則、ほんの数個のキュー、そしてプロセスはランダムな順序またはあまり良くない順序でキューに落ちます（たとえば、「シングルプロセッサ」システムがまだ新しいプロセッサで動作するために、それはあまり論理的ではないようです） 。 または、同じキュー（プロセスが取得されるプール）が1つであり、複数のキャッシュデスクがそれらを処理します。 しかし、これらはもっぱら著者の考えであり、それ以上のものではありません。
合理的な疑問が生じる場合があります。
しかし、プロセスとストリームの違いは何ですか？
そしてすべてがシンプルです。 記事の冒頭で、プログラムを実行するにはリソースとプロセッサ時間が必要であるとの記述がありました。 そのため、システムはプロセスを、プロセッサ時間を除くあらゆる種類のリソースのアプリケーションとして「認識」します。 プロセッサ時間要求はスレッドです。 そのプロセッサ時間はスレッド間で分配されます。 したがって、プロセスは複数のスレッドで構成されます。 前に、もちろん、それはすべて単一の全体でした。 そして、プロセス、フロー、そしてすべてを1つにまとめたものであり、一般的には「なぜより多くを支払うのですか？」 結局のところ、この場合、私たちはむしろ「少ない支払い」です。 複数のスレッドがある場合。
プロセスがリソースの配布を妨げるのを防ぐために、システムはそれらを「隔離」します。 それぞれに独自の仮想アドレス空間を提供します。 そのため、他のプロセスのコマンドやデータに直接アクセスできるプロセスはありません。
対話が必要な場合、プロセスは文字通り、仲介者としてOSを使用します。 そして彼女はすでに彼らを助け、コミュニケーションを提供しています。
ただし、同じプロセスのスレッド間では完全な保護はありません。 不可能であるだけでなく、誰もそれを必要としないからです。 データフローを交換するために、OSを使用する必要はありません。 共有メモリを使用します。 1つはデータを書き込み、もう1つは読み取ります。 そして、すべてが順調です。 さらに、さまざまなプロセスのスレッドは相互に十分に保護されています。
マルチプログラミングは、プロセスよりもスレッドのレベルでより効率的です。 各スレッドには、独自の命令カウンターとスタックがあります。 複数のスレッドの形のタスクは、その部分の並列実行（またはシングルプロセッサシステムでは擬似並列）により、より速く完了することができます。
明らかな発見
プロセスは、プロセッサ時間を除くすべてのリソースを消費するアプリケーションです。 プロセスは互いに分離されており、スレッドが含まれています。 実際、スレッドは、このプロセッサ時間自体の消費を求めるリクエストです。
マルチスレッド処理の導入の最大の効果は、スレッド（単一プロセスのフレームワーク内でも）がpseudoではなく実際に並列に実行できるマルチプロセッサシステムで実現されます。
さらに、[マスサービス]システムの動作の概念自体は、例によって直接示されました。
そしてPS
私は記事の最初と途中で少し「ウィスキング」し、「プロセス」自体のプロセッサー時間について話しました。 しかし、それほど多くはありません。そして、この強制的な不正確さを許してくれることを願っています。