Can a program call fflush() on the same FILE* concurrently?

Question

Can anything bad happen (like undefined behavior, file corruption, etc.) if several threads concurrently call fflush() on the same FILE* variable?

Clarification: I don't mean writing the file concurrently. I only mean flushing it concurrently.

The threads do not read or write the file concurrently (they only write the file inside a critical section, one thread at a time). They only flush outside of the critical section, to release the critical section sooner so to let the others do the other work (except file writing).

Though it may happen that one thread is writing the file (inside the critical section), while another thread(s) is flushing the file (outside the critical section).

Speechless

This sounds as though you are asking it from a design perspective, rather than trying to eliminate an explanation for a bug — perhaps it would be worth making that more explicit. – Mendelsohn

Given the answer that FILEs are thread-safe, one negative consequence could be that one thread is forced to wait for another to flush, though that would probably only matter if you require fairly high performance. Using functions like flockfile ¿or flock? could conceivably lead to deadlock, but probably not in the case you describe. – Mendelsohn

@Mendelsohn , that's all right: if one thread is flushing, and another thread writes something and then figures out it need to flush too, then all it can do is to wait for the first thread to return what's at FILE* into a consistent state (flushing everything it has written, and maybe even what the second thread has written - this depends on the race), and then the second thread should ensure that what it has just written gets flushed too. Of course there is a better approach with asynchronous flushing in a dedicated thread, but that's more complex thus out of the scope. – Speechless

You seem to assume that flushing only delays other threads also trying to flush, but my understanding of the quotes in 2501’s answer is that, since there is a single lock per stream, it also delays threads trying to write — and that could be undesirable! – Mendelsohn

Answer 1

Streams in C¹ are thread-safe². Functions are required to lock the stream before accessing it³.

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 stream⁴.

---

¹ As per the current standard, which is C11.

² (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 multiple threads of execution access a stream, and to restrict the interleaving of stream operations performed by multiple threads. Only one thread may hold this lock at a time. The lock is reentrant: a single thread may hold the lock multiple times at a given time.

³ (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 stream before accessing it. They release the lock associated with the stream when the access is complete. reentrant: a single thread may hold the lock multiple times at a given time.

⁴ (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 recent operation was not input, the fflush function causes any unwritten data for that stream to be delivered to the host environment to be written to the file; otherwise, the behavior is undefined.

Tintoretto

Does MSVC compiler follow these on x86/x86_64 Windows? – Speechless

@SergeRogatch If it is C11 compliant, then yes. – Wade

@SergeRogatch Aparently it is safe: msdn.microsoft.com/en-us/library/9yky46tz.aspx – Tintoretto

@Wade VS is not even C99 compliant. – Tintoretto

@Tintoretto Eheheh, well, what hope is there for the universe? Maybe they should just encourage their users to use Clang instead. – Wade

@2501, yes, great, for both 2013 and 2015 they say "This function locks the calling thread and is therefore thread-safe. For a non-locking version, see _fflush_nolock." on that MSDN page. – Speechless

"The lock is" What? – Joell

@black a faulty copy-paste. Thanks. – Tintoretto

C streams were not always safe. I recall having to track down a bug where they were not. Nevertheless, if you hit such a bug today, bug your compiler vendor. – Krona

@Wade Microsoft Visual C++ aims to be a C++ compiler, not a C compiler. AFAIK they do support C++14 in recent versions. – Miriam

I welcome useful corrections, but please stop editing my answer to change its look. – Tintoretto

We use fwrite and fflush with the same FILE concurrently in code compiled with MSVC 2015 without any problems. The writes are being neatly interleaved in the output file. – Venterea

Answer 2

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.

Oldster

▲ For “not POSIX compliant”, but do you mean that fflush is not thread safe, that they do not implement POSIX.1c or that they do not claim compliance? A list (or link to one) of platforms (with version information) and their compliance in this respect might be a useful resource. – Mendelsohn

I don't know if Google promises that fflush will be thread-safe, even if it currently is, but Microsoft does at least on Windows. – Oldster

Answer 3

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.

Towe

Answer 4

Pretty simple answer, you may not do that, as the file has a single "current position". How do you keep track of it? Is the file opened for sequential access or random? In the latter case you could open it multiple times (one for each thread), and yet devise ways to keep the file structure consistent.

Eulogia

Ok, I should add this to the question: the threads do not read or write the file concurrently (they only write the file inside a critical section, one thread at a time). They only flush outside of the critical section, to release the critical section sooner so to let the others do the other work (except file writing). – Speechless

fflush() does not modify the current position. – Towe

It could be easier then, I would consider a different way, create another worker thread (no windows, timers, message-queues etc) which will only be performing the flushing (or maybe the writing as well?). The thread proc would only contain a loop with a SleepEx() command. The other threads would be sending APC requests for writng, and the APC proc would execute them (one at a time, as they are queued). Implementation is only a few source lines, and you don't really need to read much, if you don't know how to do it already. See the documentation for QueueUserAPC() function. – Eulogia

Answer 5

The actual answer seems to be that streams are (meant to be) thread-safe themselves, but, if that weren't the case, your issue could be the fflush occurs (outside a lock) while another thread is writing (inside a critical section).

As such, I'd work with the model of the virtual machine you're coding against and put the fflush() inside a critical section too.

Motionless