Using the posix read() write() linux calls, is it guaranteed that if I write through one file descriptor and read through another file descriptor, in a serial fashion such that the two actions are mutually exclusive of each other... that my read file descriptor will always see what was written last by the write file descriptor?
i believe this is the case, but I want to make sure and the man page isn't very helpful on this
It depends on where you got the two file descriptors. If they come from a dup(2) call, then they share file offset and status, so doing a write(2) on one will affect the position on the other. If, on the other hand, they come from two separate open(2) calls, each will have their own file offset and status.
A file descriptor is mostly just a reference to a kernel file structure, and it is that kernel structure that contains most of the state. When you open(2) a file, you get a new kernel file structure and a new file descriptor that refers to it. When you dup(2) a file descriptor (or pass a file descriptor through sendmsg), you get a new reference to the same kernel file struct.
This is guaranteed if they both refer to the same file description, aka you got them from "dup" or "dup2" (or inherited via fork()).
After a successful return from one of these system calls, the old and new file descriptors may be used interchangeably. They refer to the same open file description (see open(2)) and thus share file offset and file status flags; for example, if the file offset is modified by using lseek(2) on one of the descriptors, the offset is also changed for the other.
when you use dup() or dup2() or fork() ,
the file table is shared by both of the file descriptors.
so if you write something from one file descriptor , and again write something through other file descriptor , then it is appended not overwritten.
but if two independent process open one file , then the data written by both processes may get mixed.
来源：https://stackoverflow.com/questions/5284062/two-file-descriptors-to-same-file