Shared FILE* concurrent writes and stdio per-stream lock latency

Answer to the core question

POSIX defines that all standard I/O functions are thread‑safe. In practice this is achieved by the library holding a mutex for each FILE stream. The lock is taken at the very beginning of a call such as fprintf() or fflush() and released at the end of that call. Therefore the granularity of the lock is *per‑function call*, not per‑byte or per‑buffer. The duration of the lock includes whatever work the function does – formatting, buffer manipulation, and, if the buffer is flushed, the system‑level write() syscall.

Does setvbuf change lock behaviour?

Changing the buffering mode with setvbuf() only affects when the library decides to flush the buffer to the underlying file descriptor. It does not alter the fact that the mutex is held for the entire life of the function that is executing. For example, switching to _IONBF will cause every fprintf() to perform a write() immediately, but the lock is still acquired and released around that single call. Consequently, the lock hold time is predictable only in the sense that it spans the whole function call, not the buffering strategy.

Using flockfile/funlockfile for latency predictability

The POSIX functions flockfile() and funlockfile() let a thread acquire the stream’s mutex explicitly. This turns a series of fprintf() (or fputs(), fputc(), etc.) into a single critical section. The lock is held from the call to flockfile() until funlockfile(), so the library does not intermix other threads’ writes between the calls you batch together. The lock still covers any flush that occurs inside the batched calls, but the overhead of repeated lock acquisition is eliminated.

Practical steps for the described scenario

1. Identify the C library in use (glibc, musl, BSD libc, etc.). The exact implementation of the mutex and the moment it is released can vary slightly.
2. Decide on a buffering strategy that matches your throughput needs. For high‑throughput logs, _IOFBF with a large buffer is common; for low‑latency single writes, _IONBF may be preferable.
3. Wrap the group of fprintf() calls that belong together in a flockfile()/funlockfile() block.
4. Never mix write() or other descriptor‑level calls on the same file descriptor while the stream is locked – that violates the stdio contract and can corrupt the buffer.
5. Measure the latency of the critical section with a high‑resolution timer (e.g., clock_gettime(CLOCK_MONOTONIC, …)) and compare it to the sum of individual calls to confirm the benefit.

What to ask next to tighten the recommendation

Could you specify which C library you are compiling against (glibc, musl, or a BSD implementation)? Different libraries may expose subtle differences in the exact moment the lock is released, especially when a flush triggers a blocking write(). Knowing that will let us provide a more precise latency model for your environment.