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