Messages in this thread | | | Date | Thu, 13 Apr 2006 15:06:03 -0700 | From | Dan Bonachea <> | Subject | Re: PROBLEM: pthread-safety bug in write(2) on Linux 2.6.x |
| |
At 02:50 PM 4/13/2006, Alan Cox wrote: >The only serious case historically has been O_APPEND which does have >pretty precise semantics. Nowdays we also have pread/pwrite which have >pretty clear semantics and deal with threading. The O_APPEND case is >very important to get correct and 2.4 certainly did so. ... >As such I belive that the O_APPEND case must be kept locked properly and >the non O_APPEND cases are already correctly handled by the kernel. That >seems to argue for f_pos serialization on O_APPEND only.
I agree that O_APPEND is important to get correct. However, would that also handle the specific case of stdout redirection to a file? (ie "a.out > result", not just "a.out >> result" - the latter incidentally does not currently seem to fail, at least with my tests)
>Looking at the spec it says the following > >"If the O_APPEND flag of the file status flags is set, the file offset >shall be set to the end of the file prior to each write and no >intervening file modification operation shall occur between changing the >file offset and the write operation." > >This is what 2.4 took great paints to guarantee for file writes. Now in >actual fact no OS I know of implements this to the extreme (mmap) but >does for the other cases. > >Outside of O_APPEND the specification says only that >- The write starts at the file position >- The file position is updated before the syscall returns > >It makes no other guarantee I can see.
The POSIX 1003.1-2001 spec seems to provide a very clear guarantee of thread-safety behavior wrt threads:
2.9.1 Thread-Safety All functions defined by this volume of IEEE Std 1003.1-2001 shall be thread-safe, except that the following functions need not be thread-safe. <omitted list of functions, which does not include write> Implementations shall provide internal synchronization as necessary in order to satisfy this requirement. ... 2.9.7 Thread Interactions with Regular File Operations All of the functions chmod( ), close( ), fchmod( ), fcntl( ), fstat( ), ftruncate( ), lseek( ), open( ), read( ), readlink( ), stat( ), symlink( ), and write( ) shall be atomic with respect to each other in the effects specified in IEEE Std 1003.1-2001 when they operate on regular files. If two threads each call one of these functions, each call shall either see all of the specified effects of the other call, or none of them.
Unless I'm missing something, that doesn't leave much ambiguity regarding what's required for POSIX compliance on this issue (although I'm not sure POSIX compliance is the right metric).
Dan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |