从多个线程fopen和fwrite到同一文件

Question

This is similar but a bit different to existing questions. Say I have many threads that open the same file but they all do their own fopen and maintain their own FILE pointer. a) is it necessary to lock fwrite calls if they have their own FILE ptrs? b) if it is necessary, is locking around fwrite enough or will they potentially flush at different times and end up intermingling when they flush? If yes, would locking on fwrite and then fflush cover it?

Answer 1

This question can not be answered in the context of programming languages. As far as programming language is concerned, those file handles are completely independent objects, and whatever you do with one has no effect whatsoever on another.

The question is on the operating system - can it handle multiple write operation to the same underlying file at the same time. In other words, are those writes atomic . I can't say for all of them, but in Linux, for example, writes for less than PIPE_BUF size are atomic.

Answer 2

For the quick measure, yeah, you can put a lock around the I/O part. That'd work, I guarantee it. As for flusing I/O cache, I'd recommend not doing that. It's always best to let OS to handle I/O timing because kernel knows what's going on the best. You are not gonna have it in effect immediately after calling flush anyway because it's that complicated. Just like the other flush operations(java GC, glFlush and so on). If you choose to stick to this option, please be mindful of a start and an end point of the concurrent I/O op. You wouldn't want a case where the main thread closes the file and another worker thread tries to do I/O on that.

The general solution to this problem is creating a thread that handles the file exclusively. If other thread should read/write from/to the file, they must ask the thread to do that for them. This is tricky, I know. You'd need to compose a simple protocol, sync mechanism, but in a nutshell, it goes like this:

1. prep a queue, a cv(condition variable), a lock. create a thread and open the file. Doesn't matter who opens the file
2. The thread spawns and waits for the queue to be filled in
3. Other threads send a request I/O op to the thread. The request includes the data for the file and an op code.
4. The thread handles the requests from the queue. This is where the real I/O happens.

You could use anonymous FIFO instead of a queue. Or skip the opcode part if the file is write-only.

Unlike network I/O, modern OSes can't do file I/Os in a non-blocking manner. So expect a significant blocking time(io wait). Also, there's this problem where the queue fills up too quick and eats a lot of memory when I/O is relatively slow. There will be a case where the whole program should wait for the I/O to complete before terminating itself. Not much you can do about it. You could close the file from another thread while I/O is in progress on Linux( close() is MT-safe ), I don't know how that's gonna work on other OS.

There are alternatives like async file I/O or overlapped I/O which involves signal handling or callbacks. Using these doesn't require a creating of a thread but each has pros and cons, mostly regarding portability.