システムコールとコンテキストスイッチ
この質問は、既に質問された場合は申し訳ありませんが、明確にすることができませんでした。したがって、システムコール（モードスイッチ）とコンテキストスイッチの違いを理解するために、次の関連する質問をします。
呼び出しを行っているプロセスのコンテキストを保存して再ロードする必要がある場合、システムコールでコンテキストスイッチが不要であると言われているのはなぜですか。それは、コンテキストスイッチの定義に従って、別のプロセスに切り替える必要があるからです。
システムコールが行われると、カーネルは「ユーザーコンテキスト」で実行されるという意味です。
ウィキペディアの記事によると： http://en.wikipedia.org/wiki/Context_switch
システムコールにコンテキストスイッチは必要ありませんが、オペレーティングシステムによって異なり、システムコール中にコンテキストスイッチが発生する可能性があります。システムコール時にコンテキストスイッチが発生した場合はどうなるのでしょうか。例はありますか？
スレッド/プロセスコンテキストには複数の部分があり、1つは実行に直接関連付けられ、CPUとCPUが使用するメモリ内の特定のシステムテーブル（ページテーブルなど）に保持され、もう1つは必要なことを理解する必要があります。簿記のためのOS（さまざまなID、ハンドル、特別なOS固有のアクセス許可、ネットワーク接続などを考えてください）。
完全なコンテキスト切り替えには、これらの両方の交換が含まれます。古い現在のスレッド/プロセスはしばらくの間消え、新しい現在のスレッド/プロセスはしばらくの間入ります。それがスレッド/プロセスのスケジューリングの本質です。
現在、システムコールはw.r.tとは大きく異なります。お互い。
たとえば、現在の日付と時刻を要求するシステムコールなど、簡単なものを考えてみます。 CPUはユーザーモードからカーネルモードに切り替え、ユーザーモードレジスタ値を保持し、必要なデータを取得するためにいくつかのカーネルコードを実行し、呼び出し元がアクセスできるメモリまたはレジスタに格納し、ユーザーモードレジスタ値を復元します。戻り値。ここにはコンテキストスイッチの多くはなく、モード、ユーザー、カーネル間の移行に必要なものだけです。
イベントまたはデータが利用可能になるまで呼び出し元をブロックするシステムコールを考えてみます。 mutexの操作とファイルの読み取りは、このようなシステムコールの例です。この場合、カーネルは呼び出し元の完全なコンテキストを保存し、ブロックされているものとしてマークし、スケジューラがそのイベントまたはデータが到着するまで実行できないようにし、別の準備ができているスレッド/プロセスのコンテキストをロードして実行できるようにします。
これが、システムコールとコンテキストスイッチの関係です。
カーネルがユーザーまたはプロセスのコンテキストで実行されるということは、カーネルが特定のプロセスまたはユーザーの代わりに機能する場合は常に、そのユーザー/プロセスのコンテキストを考慮する必要があることを意味します。現在のプロセス/スレッド/ユーザーID、現在のディレクトリ、ロケール、さまざまなリソース（ファイルなど）のアクセス許可など、さまざまなプロセス/スレッド/ユーザー間で異なる可能性があります。
プロセスに個別のアドレススペースがある場合、アドレススペースもプロセスコンテキストの一部です。したがって、カーネルがプロセスのメモリにアクセスする必要がある場合（ファイルデータまたはネットワークパケットを読み書きするため）は、プロセスのアドレス空間IOWにアクセスできる必要があります。ただし、特定のアドレス空間のメモリにアクセスするためだけに、カーネルは完全なコンテキストをロードする必要があります）。
役に立ちましたか？