2

stdio.h FILE直接read()/よりも使用する利点の1つwrite()は、バッファリング、割り込み処理などであることを理解しています。したがって、理解しているように、fwrite()を実行するまですべてのがバッファリングされますfclose()。ここまでは順調ですね。さて、これを行うとfclose()、データがディスクにフラッシュされるまでブロックしますか、それともfclose()データをOSに渡して、暇なときにディスクにフラッシュさせた後、すぐに戻りますか？

4

2 に答える 2

3

多くのレベルでバッファリングがあり、これは OS やその他の多くのものに依存します。

通常、アプリケーション内の FILE* には内部バッファがあり、ファイル (または FILE* が接続されているデバイス) にフラッシュされます。

  • 内部 FILE* バッファがいっぱいになったとき
  • 改行を書いたとき (バッファリングされた行の場合 FILE*)
  • ファイルを閉じるとき*
  • fflush() を呼び出すとき
  • FILE* もバッファリングされていない可能性があります

通常のディスク ファイルの場合、ほとんどの OS はカーネル内にバッファリングを備えているため、FILE* バッファのフラッシュには、多かれ少なかれ、アプリケーションのバッファから OS カーネルへのメモリのコピーが含まれ、カーネルが処理します。 fclose() が「すぐに」返される原因となる、実際のファイルに非同期で書き込みます。

データが OS/カーネル バッファにコピーされる前に、OS が最初にいくつかのハウスキーピングを行う必要がある状況が発生する可能性があります。余裕があり、すぐには戻らない。

要するに、それは依存し、あなたはそれを制御することはできません. 通常、実行できる「最善」の方法は、プラットフォームに依存する API を使用することです。これにより、少なくとも OS バッファーを物理ファイルにフラッシュできます (posix fsync()/fdatasync() API など)。

于 2012-02-21T09:44:06.253 に答える
0

あなたの理解は（少なくとも部分的に）間違っています。

I/O はバッファリングされますが、バッファ サイズには制限があります。バッファーがオーバーフローすると、フラッシュされます。また、多くのストリームはライン バッファリングされます。改行を書き込むと、バッファがフラッシュされます。そうでない場合、端末への出力は、プログラムの終了時にすべての出力が表示されるため、かなり非現実的です。

それ以外の場合、呼び出しが必ずしもブロックされているとは思いません。たとえば、基礎となるメディアが書き込みと同期されていることを確認しようとする関数があります。これは一般的に、「低レベル」になり、ソフトウェアだけでなく、ハード ドライブなどのハードウェアでもキャッシュとバッファの複雑さに対処する必要があるという問題を引き起こします。

于 2012-02-21T09:32:12.907 に答える