What happens fwrite/fread at the same time?

Hello,

I have a question about what happens when I copy the file which is being written by another process on Solaris 9/SPARC, UFS file system.

in particular, I want to know what happens while some process is reading the file using fread or mmap, another process try to write something on the exactly same place where is read by other process.

in the situation described above, does fwrite causes error? or both system call suceeds?

If you know there is some document or specification defines about confliction of read/write/mmap, please tell me.

(sorry if my English or manner is not good, I've never been post a question in these kind of forums)

Thanks.

It explodes in a giant firey ball probably visible from space.

Well... not really. This is what we call a 'race condition'. It's not an error condition, but you're not likely to get what you wanted either. If the write happens first, the reading process sees what you wrote. If the write happens last, the reading process doesn't see the changes. If you're writing in chunks, you might even get something inbetween. So it doesn't blow up but it's not predictable, either, which is almost as bad!

To make this situation predictable one should use file area locks, or mutexes, and so forth.

In the case of fread()/fwrite() it's even worse than that.

Both fread() and fwrite() by default buffer IO within the process's address space, so the OS may not even know that the application has made either call.

If you want to do concurrent access like that, you should probably use lower-level calls like read() and write(). Even then, you need to be concerned with applications not "seeing" things like changes in file size, for example.

And you do NOT want to be trying this on an NFS file system.

> Corona688
> achenle
Thank you for answering my question.

is that mean, in the other words, when fread/fwrite called at the same time on same chunk of the file, both function call doesn't return an error but the result of fread would be unpredictable...is that right?? it means result of fwrite is not affected by the fread function call?

Okay. I will:)

So actual device I/O may not occur at the same time as fwrite/fread function is called, isn't it? Can I trust operating system to sync the data passed to fwrite on the disk certainly in spite of the fact that fread is called simultaneously? (Of course, unless somebody pull out the plug of the computer before operating system sync the data in the buffer...)

now I think that I almost understand what happening behind the fread/fwrite anyway.

Thanks.

Exactly. Unless you use some form of locking, the order is unpredictable.

You can't trust fwrite() to sync at all, unless you fflush() after.

What fwrite does is call write(), if it has enough data, otherwise it just stores it to write later.

write() and read() are the actual system calls. They're not library functions, there's no deeper inside your program to go. At the point they get called, your program literally just stops until the kernel's done its job. So it's the kernel which decides what order they run in, and it won't enforce any particular order unless you've told it to.

1 Like