Can a program call fflush() on the same FILE* concurrently?
Streams in C1 are thread-safe2. Functions are required to lock the stream before accessing it3.
The fflush function is thread-safe and may be called from any thread at any time, as long as the stream is an output stream or an update stream4.
1 As per the current standard, which is C11.
2 (Quoted from: ISO/IEC 9899:201x 7.21.3 Streams 7)
Each stream has an associated lock that is used to prevent data races when multiplethreads of execution access a stream, and to restrict the interleaving of stream operationsperformed by multiple threads. Only one thread may hold this lock at a time. The lock isreentrant: a single thread may hold the lock multiple times at a given time.
3 (Quoted from: ISO/IEC 9899:201x 7.21.3 Streams 8)
All functions that read, write, position, or query the position of a stream lock the streambefore accessing it. They release the lock associated with the stream when the access iscomplete.reentrant: a single thread may hold the lock multiple times at a given time.
4 (Quoted from: ISO/IEC 9899:201x 7.21.5.2 The fflush function 2)
If stream points to an output stream or an update stream in which the most recentoperation was not input, the fflush function causes any unwritten data for that streamto be delivered to the host environment to be written to the file; otherwise, the behavior isundefined.
The POSIX.1 and C-language functions that operate on character streams (represented by pointers to objects of type FILE) are required by POSIX.1c to be implemented in such a way that reentrancy is achieved (see ISO/IEC 9945:1-1996, ยง8.2).
This requirement has a drawback; it imposes substantial performance penalties because of the synchronization that must be built into the implementations of the functions for the sake of reentrancy. POSIX.1c addresses this tradeoff between reentrancy (safety) and performance by introducing high-performance, but non-reentrant (potentially unsafe), versions of the following C-language standard I/O functions: getc(), getchar(), putc() and putchar(). The non-reentrant versions are named getc_unlocked(), and so on, to stress their unsafeness.
Note however as others have noted: Many popular systems (including Windows and Android) are not POSIX compliant.
You are not supposed to call fflush() on an input stream, it invokes undefined behavior, so I shall assume the stream is open in write or update mode.
If the stream is open in update mode ("w+" or "r+"), the last operation must not be a read when you call fflush(). Since the stream is used in various threads asynchronously, it would be difficult to ensure this without some form of interprocess communication and synchronization or locking if you do any reads. There is still a valid reason to open the file in update mode, but make sure you do not do any reads after you start the fflush thread.
fflush() does not modify the current position. It merely causes any buffered output to be written to the system. The streams are usually protected by a lock, so calling fflush() in one thread should not mess the output performed by another thread, but it may change the timing of the system writes. If multiple threads output the the same FILE*, the order in which the interleaving occurs is indeterminate anyway. Furthermore, if you use fseek() is different threads for the same stream, you must use a lock of your own to ensure consistency between the fseek() and the following output.
Although it seems OK to do it, it is probably not recommended. You could instead call fflush() after the write operations in each thread, before releasing the lock.