fprintf线程安全吗？ The glibc manual似乎是这样说的，但是我的应用程序使用单个调用fprintf（）写入文件似乎是在混合来自不同进程的部分写入。
编辑：为了澄清，有问题的程序是lighttpd插件，服务器正在运行多个工作线程。
查看该文件，其中一些写入混合在一起。
编辑2：我看到的问题似乎可能是由于lighttpd的“工作线程”实际上是单独的流程： http://redmine.lighttpd.net/wiki/lighttpd/Docs:MultiProcessor
问题
通过运行2个或更多进程 相同的插座你会有更好的 并发，但会有一些 你必须要注意的缺点 的：
- mod_accesslog可能会创建损坏的访问日志，因为同一个文件会被打开两次并且不会同步。
- mod_status将有 n 单独的计数器，每个计数器一组 过程
- mod_rrdtool将失败，因为它会两次收到相同的时间戳。
- mod_uploadprogress将无法显示正确的状态。
答案 0 :(得分：14)
你混淆了两个概念 - 从多个线程编写和从多个进程编写。
在一个进程内部，可以确保在下一个进程被允许访问输出缓冲区之前完成一次fprintf调用，但是一旦你的应用程序将该输出泵送到一个文件，你将受操作系统的支配。如果没有某种基于操作系统的锁定机制，您就无法确保完全不同的应用程序不会写入您的日志文件。
答案 1 :(得分：7)
听起来像你需要阅读file locking。您遇到的问题是多个进程（即非线程）同时写入同一文件，并且没有可靠的方法来确保写入是原子的。这可能导致文件覆盖彼此的写入，混合输出和完全不确定的行为。
这与线程安全无关，因为这仅适用于单进程多线程程序。
答案 2 :(得分：2)
当前的C ++标准对并发没有任何用处，1990 C标准也没有用。 （我还没有读过1999 C标准，所以不能评论它;即将推出的C ++ 0x标准确实会说些什么，但我不知道到底是什么。）
这意味着fprintf（）本身既不是线程安全的，也不是其他的，并且它将取决于实现。我已经准确地阅读了glibc文档中有关它的内容，并将其与您正在做的事情进行比较。