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

The goal is to characterize latency behavior of the C standard I/O library when multiple threads write concurrently to the same FILE* object.

The C standard defines concurrent access without explicit synchronization as undefined behavior, and POSIX implementations typically serialize access with a per-stream lock acquired on entry to most stdio functions. Lock hold time includes formatting, buffering and potentially blocking I/O, and the exact granularity and interaction with buffering is implementation-defined.

The design decision is unresolved between relying on implicit stdio locking with default buffering versus changing buffering with setvbuf and using explicit flockfile/funlockfile critical sections to reduce lock hold time and improve predictability. Mixing stdio with direct descriptor I/O is undefined and can corrupt buffers.

What lock granularity is documented for fprintf, fflush and related functions in the target C library? Does changing buffering mode with setvbuf change lock hold characteristics in a predictable way across implementations? Is explicit flockfile critical section around batched writes a documented way to improve latency predictability compared to implicit locking?