Linux open() file descriptor

If I open a same file(.txt file) a few times in different threads, the file descriptor returned would be different. If I tried to write() using the file descriptor, any chance of the write function be blocked since when the multiple threads trying to write to the same file?

My concern is when a thread call write to a single file, when the other thread开发者_运维知识库 call to write to the same file as well. So will the write of the second thread wait for the write of the first thread to finish first? If it is the case, how do I ensure that the second call to write would not wait and would return immediately if there is a first write as I don't want the write of second thread to wait.

Thanks

No, but the latest write() will always clobber earlier writes if they're writing to overlapping regions of the file.

A more common question regards the file offset of writes, which may be your true question. In this case the answer is: Not if you call open() from each thread. Writes will occur at the file offset remaining from the last write() to any descriptors originating from the same original open() call, such as those obtained by dup(), or shared by threads in the same process.

If you have multiple threads sharing the same resource (in your case, a file), it's your responsibility to use some sort of synchronization (for example, a semaphore or mutex) to ensure that only one write is in progress at any time. Otherwise, the results will be undefined. Unix will not keep track of this for you -- if you start a write in one thread while a write to the same file is in progress in a different thread, no blocking will occur. The writes will complete promptly, with no guarantees about the ordering of I/O operations to the underlying physical device -- they could even be interleaved.

Regardless of whether you use processes or threads, writing to the same file at the same time is likely to cause problems unless it's done very carefully.

It doesn't matter if the file descriptor is the same number or not.

write() will not usually block when writing a disc file because the changes will just go into the OS cache. It doesn't matter how many tasks are doing this.

However, if you write to a file from several processes, you're likely to end up with garbage in the file as the ordering of the writes will be nondeterministic.

If you wanted to write to different parts of the same file in multiple threads, then you can use pwrite() to write to a specific place in the file, and multiple threads can share the same file descriptor. This is ok if your threads are doing the right thing.

This technique normally doesn't work with text files. Text files normally need to be written only by one thread at once to get predictable content in.

You can open a file in write mode (in which case writes can clobber each other), or you can open it in append mode (in which case the OS will lock and ensure each write completes atomically, with future write - from whatever thread - directed to the new end of file).

So, use append mode. Your thread will quickly shift the data into a kernel queue (assuming you're flushing), and you get on with things. If you find even that's not fast enough, then you can try to move data from your individual thread into a thread that's dedicated to doing the file updates, but get a working system with the simpler, cleaner implementation first then profile.