glibcのfprintf（）の実装はスレッドセーフですか？

Question

fprintfはスレッドセーフですか？ The glibc manualはそうだと言えますが、fprintf（）を一度呼び出すだけでファイルに書き込む私のアプリケーションは、異なるプロセスからの部分書き込みを混在させるようです。

編集：問題のプログラムはlighttpdプラグインであり、サーバーは複数のワーカースレッドで実行されています。

ファイルを見ると、いくつかの書き込みが混在しています。

編集2：私が見ている問題が原因のlighttpdの「ワーカースレッド」は、実際に独立したプロセスであることにあるかもしれないようだ。http://redmine.lighttpd.net/wiki/lighttpd/Docs:MultiProcessor

問題

2つの以上のプロセスを実行することで 同じソケット上で、あなたはより良い 並行性を持つことになりますが、あなたは を認識する必要があり、いくつかの の欠点があります：

を0

• mod_accesslogは、同じファイルが2回開いて同期されないため、壊れたアクセスログを作成することがあります。
• mod_statusには、それぞれ プロセスごとに1つずつ、n個のカウンタがあります。
• mod_rrdtoolは同じタイムスタンプを2回受信すると失敗します。
• mod_uploadprogressは正しいステータスを表示しません。複数のスレッドからの書き込みと複数のプロセスからの書き込み -

Answer 1

は、次の2つの概念を混乱させています。

fprintfの1回の呼び出しが次の前に完了することを保証するために、出力バッファへのアクセスが許可されますが、アプリケーションがその出力をファイルにパンプすると、OSが慈悲に満ちています。ある種のOSベースのロック機構がなければ、まったく異なるアプリケーションがログファイルに書き込まないようにすることはできません。

Answer 2

file lockingにお読みください。問題は、複数のプロセス（つまりスレッドではない）が同じファイルに同時に書き込みを行っていることと、書き込みがアトミックになることを確実にする確実な方法がないことです。これは、ファイルが互いの書き込み、混合出力、および完全に非決定論的な動作を上書きすることになります。

これはスレッドセーフティとは関係ありません。これは、シングルプロセスのマルチスレッドプログラムにのみ関係します。

Answer 3

現在のC++標準では、並行性については何も言及していませんし、1990 C標準についても何も言及していません。 （私は1999年のC標準を読んでいないので、それについてコメントすることはできません;今後のC++ 0x標準は何かを言っていますが、どういうことかわかりません）

これは、fprintf ）自体は、スレッドセーフでもなくても、実装に依存する可能性があります。私はglibcのドキュメントに書かれていることを正確に読んで、あなたがやっていることとまったく同じものを比較したいと思います。