fprintf 是线程安全的吗？ glibc手册似乎说它是，但是我的应用程序使用对 fprintf() 的单个调用写入文件，似乎混合了来自不同进程的部分写入。
编辑：为了澄清，有问题的程序是一个 lighttpd 插件，并且服务器正在使用多个工作线程运行。
查看该文件，一些写入是混合的。
编辑2：看来我看到的问题可能是由于lighttpd的“工作线程”实际上是单独的进程： http://redmine.lighttpd.net/wiki /lighttpd/Docs:多处理器
问题
通过在上运行 2 个或更多进程
同样的插座你会有更好的
并发，但会有一些
你必须注意的缺点
的：
- mod_accesslog 可能会创建损坏的访问日志，因为同一个文件被打开两次并且不同步。
- mod_status 将有 n 个独立的计数器，每个计数器一组
过程。
- mod_rrdtool 将失败，因为它两次收到相同的时间戳。
- mod_uploadprogress 将不会显示正确的状态。
Is fprintf thread-safe? The glibc manual seems to say it is, but my application, which writes to a file using single call to fprintf() seems to be intermingling partial writes from different processes.
edit: To clarify, the program in question is a lighttpd plugin, and the server is running with multiple worker threads.
Looking at the file, some of the writes are intermingled.
edit 2: It seems the problem I'm seeing might be due to lighttpd's "worker threads" actually being separate processes: http://redmine.lighttpd.net/wiki/lighttpd/Docs:MultiProcessor
Problems
By running 2 or more processes on the
same socket you will have a better
concurrency, but will have a few
drawbacks that you have to be aware
of:
- mod_accesslog might create broken access logs, as the same file is opened twice and is NOT synchronized.
- mod_status will have n separate counters, one set for each
process.
- mod_rrdtool will fail as it receives the same timestamp twice.
- mod_uploadprogress will not show correct status.
发布评论
评论（3）
您混淆了两个概念 - 从多个线程写入和从多个进程写入。
在进程内部，可以确保 fprintf 的一次调用在允许下一次调用访问输出缓冲区之前完成，但是一旦您的应用程序将该输出泵送到文件中，您就受到操作系统的支配。 如果没有某种基于操作系统的锁定机制，您就无法确保完全不同的应用程序不会写入您的日志文件。
You're confusing two concepts - writing from multiple threads and writing from multiple processes.
Inside a process its possible to ensure that one invocation of fprintf is completed before the next is allowed access to the output buffer, but once your app pumps that output to a file you're at the mercy of the OS. Without some kind of OS based locking mechanism you cant ensure that an entirely different application doesnt write to your log file.
在我看来，您需要阅读文件锁定 。 您遇到的问题是多个进程（即不是线程）同时写入同一个文件，并且没有可靠的方法来确保写入是原子的。 这可能会导致文件覆盖彼此的写入、混合输出以及完全不确定的行为。
这与线程安全无关，因为这仅与单进程多线程程序相关。
Sounds to me like you need to read on file locking. The problem you have is that multiple processes (i.e. not threads) are writing to the same file simultaneously and there is no reliable way to insure the writes will be atomic. This can result in files overwriting each other's writes, mixed output, and altogether non-deterministic behaviour.
This has nothing to do with Thread Safety, as this is relevant only in single-process multithreading programs.
当前的 C++ 标准没有提及任何关于并发的有用信息，1990 年的 C 标准也没有提及。 （我还没有读过 1999 年的 C 标准，所以无法对其发表评论；即将推出的 C++0x 标准确实说了一些事情，但我不知道具体是什么。）
这意味着 fprintf() 本身很可能既不是线程安全的也不是其他的，并且这取决于实现。 我准确地阅读了 glibc 文档的内容，并将其与您正在做的事情进行比较。
The current C++ standard says nothing useful about concurrency, nor does the 1990 C standard. (I haven't read the 1999 C standard, so can't comment on it; the upcoming C++0x standard does say things, but I don't know exactly what offhand.)
This means that fprintf() itself is likely neither thread-safe nor otherwise, and that it would depend on the implementation. I'd read exactly what the glibc documentation says about it, and compare it to exactly what you're doing.