遅いシステムコールと速いシステムコールの違い
遅いシステムコールと速いシステムコールの違いは何ですか？キャッチされたシグナルがブロックされたシステムコールを起動する可能性があるため、プロセスがいくつかのシグナルをキャッチすると、遅いシステムコールがブロックされる可能性があることを学びましたが、このメカニズムを正確に理解できません。任意の例をいただければ幸いです。
システムコールには、実際には3つの段階があります。
- 一部のシステムコールはすぐに戻ります。 「すぐに」とは、彼らが必要とする唯一のことは少しのプロセッサ時間であることを意味します。所要時間に厳密な制限はありませんが（ リアルタイムシステム を除く）、これらの呼び出しは、十分に長い時間がスケジュールされるとすぐに戻ります。
これらの呼び出しは通常非ブロッキングと呼ばれます。非ブロッキング呼び出しの例は、システム状態の一部を読み取るだけの呼び出し、またはgetpid、gettimeofday、getuidまたはsetuid。一部のシステムコールは、状況に応じてブロックされる場合とブロックされない場合があります。たとえば、readファイルがパイプまたは非ブロッキング読み取りをサポートするその他のタイプである場合、ブロックしないでくださいO_NONBLOCKフラグ が設定されます。 - いくつかのシステムコールは完了するまでに時間がかかる場合がありますが、永遠ではありません。典型的な例は
sleepです。 - 一部のシステムコールは、外部イベントが発生するまで戻りません。これらの呼び出しはblockingと呼ばれます。たとえば、ブロッキングファイル記述子で呼び出された
readはブロッキングであり、waitもブロッキングです。
「高速」システムコールと「低速」システムコールの違いは、非ブロッキングvsブロッキングに近いですが、今回はカーネル実装者の観点からです。高速なsyscallは、ブロックまたは待機せずに完了することができることが知られているものです。カーネルは、高速なsyscallを検出すると、syscallをすぐに実行し、同じプロセスをスケジュールされた状態に保つことができることを認識しています。 （ non-preemptive マルチタスクを使用する一部のオペレーティングシステムでは、高速システムコールは非プリエンプティブになる可能性があります。これは通常のUNIXシステムではそうではありません。）一方、低速のシステムコールは別のシステムコールを待機する必要がある可能性があります。タスクが完了するため、カーネルは呼び出しプロセスを一時停止して別のタスクを実行する準備をする必要があります。
一部のケースは少し灰色の領域です。たとえば、ディスクの読み取り（通常のファイルからのread）は、別のプロセスを待機していないため、通常は非ブロッキングと見なされます。ディスクを待っているだけで、通常は応答するのに少し時間がかかりますが、永久にかかることはありません（そのため、上記のケース2です）。しかし、カーネルの観点からは、プロセスはディスクドライバーが完了するのを待たなければならないので、システムコールは明らかに遅くなります。
遅いシステムコールは、TCP socket read（）のようなものです。O_ASYNC（または何でも）が設定されていない場合、待機する可能性があります。
高速システムコールは、gettimeofday（）またはgetpid（）のようなもので、どちらもカーネルがすぐに利用できるプロセスに情報を返します。
ディスク読み取りは、遅いシステムコールのカテゴリに分類されます。プロセスが実際のディスクファイル、ファイル記述子に対してread（）を実行する場合、カーネルは、1つ以上のディスクブロックを読み取って、その読み取りを満たす必要がある場合があります。基盤となるファイルシステムのディスク上の構造に応じて、これはディスク上のiノードを読み取って「間接ブロック」のディスクブロック番号を取得し、間接ブロックを読み取ってデータブロックを取得し、データブロック自体を読み取ることを意味します。 。少なくともディスクアクセスあたりのCPUサイクルの点ではかなりの時間がかかりますが、今日は古き良き時代よりもひどいものです。
私はこれを長い間見たことがありませんが、古いUnixディスクドライブのデバイスドライバーコードの「下半分」はシグナル/割り込みをブロックするため、ディスク上のファイルシステムの整合性を維持するのが簡単でした。ときどき、バグのあるドライバや障害のあるディスクは、プロセスが要求したディスクブロックを提供せず、プロセスが永久にスリープ状態になることがあります。殺す-9でさえ、それに対して何もしませんでした。