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