画面に印刷すると、カーネルモードに切り替わり、UNIXでOSコードが実行されますか？

Question

私はテストのために勉強しているのはOS（unixは私たちのモデルです）です。 私は以下の質問をしています：

次のうち2つは、ユーザーのプログラムが停止してOSコードに切り替わることはありませんか？

A.プログラムがエラーを検出し、 が画面に表示されています。

B.プログラムは、 がディスクから後で読み取られるメモリを割り当てました。

しかし、私は答えがありますが、どれくらい良いか分かりません。 答えはB. ですが、Bはユーザがmallocシステムコールを使用していない場合ですか？メモリの割り当てはOSを経由しないのですか？ なぜ画面に印刷するにはOSが必要なのですか？あなたの助け

Answer 1

In Aユーザープログラムは、エラーを検出し、その情報の提供方法を​​決定する責任があります。しかし、ほとんどの場合、実際にディスプレイデバイスまたは端末に文字をレンダリングするには、ある時点でOSコールが必要になります。

OSは確かにメモリ管理を担当しており、ある時点でOSからのメモリを要求したり、OSがディスクスワップを提供しなければならないことがあります。

したがって、答えはおそらく厳密にはどちらもありません。しかし、はにはシステムコールが必要ですが、B にはにシステムコールが必要です。

Answer 2

mallocため

おかげでシステムコールではありません。それは単なる関数です。

mallocに電話すると、（内部的に）十分なメモリがあるかどうかがチェックされます。そうであれば、アドレスを返すだけで、カーネルモードにトラップする必要はありません。それがない場合は、オペレーティングシステム（実際にはシステムコール）に問い合わせます。

印刷の仕方によっては、それもシステムコールを引き出すことがあります。たとえば、stdioを使用すると、印刷はユーザー・バッファーになります。つまり、printfは実際のI/Oなしでstdioバッファにコピーすることを意味します。 の場合、printfがフラッシュすることを決定した場合、実際にはシステムコールを実行する必要があります。

Answer 3

答えはA.です。検出された後のエラーの処理は、プログラミング言語の実行時間とユーザー空間アプリケーションによって処理されます。一方、ファイルをmmapすると、必要なページを割り当て、ディスクIOをキューに入れるためにカーネルモードに入る必要があります。だから、Bは間違いなく正しいオプションです。

Answer 4

printf()とmalloc()呼び出しは、Cランタイムライブラリ（libcの）を呼び出します。 Cランタイムライブラリはカーネルの上にあるレイヤーで、場合によってはカーネルを呼び出すことになります。

カーネルは、brk()（データセグメントの拡張/縮小）とmmap()（プロセスの仮想アドレス空間へのメモリのマップページ）を介していくらか基本的なメモリ割り当てを提供します。 Libcのmalloc()は、カーネルから取得したメモリを内部的に管理し、システムコールを最小限に抑えようとします（特に過度の断片化を防ぎ、マルチスレッドプログラムで良好なパフォーマンスを発揮しようとします） 。

stdio入力/出力（*printf()/*scanf()経由）はバッファリングされ、カーネルのwrite()/read()システムコールを呼び出すことになります。デフォルトではstderr（エラーストリーム）はバッファリングされていないか、またはラインバッファされています（ISO C§7.19.3¶7）。 stdinおよびstdoutは、インタラクティブデバイスに接続されていないと判断できない限り、ラインバッファリングまたはバッファリングされないため、入力用のインタラクティブプロンプトが正しく動作します。 stdinおよびstdoutは、ディスクファイルまたは他の非インタラクティブストリームを参照する場合、完全にバッファリング（ブロックバッファリング）できます。

つまり、エラー出力は、setbuf()/setvbuf()を使用しない限り、'\n'（改行）文字を出力するとすぐに表示されることが保証されています。通常の出力は、その保証を提供するために、端末または他の対話型装置に接続する必要があります。