Hi there, On Thu, 30 Mar 2006, 08:41:52 +0200, Verdi March wrote:
Hi,
--- Ursprüngliche Nachricht --- Von: Anders Johansson
An: suse-programming-e@suse.com Betreff: Re: [suse-programming-e] The meaning of atomic in write() Datum: Wed, 29 Mar 2006 18:28:23 +0200 No, that's not what I said. Atomic means "uninterrupted". It means each call to write() will be allowed to complete before another call gets access to it.
However, what I missed in my hazy thinking was that the file descriptor is copied, not shared, so each process has its own idea of where to write in the file. file locking or record locking won't help in this case, you need some other way of letting the processes cooperate, so they know where in the file to write
I think you're right, that "atomic" does not cover the location to start writing. If I changed my program a little bit: [...]
I'm afraid everyone in this thread expects something that *buffered I/O* cannot provide. Opening a file using "fopen" creates a FILE structure with some buffer attached to it - unless the file to be opened appears to be an interactive device. If you really want to use the high-level (3) routines (fopen, fprintf, fread, fwrite, ...) _and_ want to ensure that no buffering inside a library is getting in your ways, you need to, at least, call "setbuf (fp, NULL)" to ensure *no* buffering will happen. BUT, it will not change anything wrt/ HOW the underlying kernel will deal with (non synchronous) write's going to the file - that's what you've seen. IF you want to change this, you need to take care there's a proper protocol for dealing with synchronous I/O used by your application; did you try something like fd = open ("path", O_CREAT | O_TRUNC | O_DIRECT, 0644); fp = fdopen (fd, "rw"); (proper checking of return codes assumed!)? Still, according to the "open(3)" manual page: O_DIRECT Try to minimize cache effects of the I/O to and from this file. In general this will degrade performance, but it is useful in special situations, such as when applications do their own caching. File I/O is done directly to/from user space buffers. The I/O is synchronous, i.e., at the completion of a read(2) or write(2), data is guaranteed to have been transferred. Under Linux 2.4 transfer sizes, and the alignment of user buffer and file offset must all be multiples of the logical block size of the file system. Under Linux 2.6 alignment to 512-byte bound‐ aries suffices. A semantically similar interface for block devices is described in raw(8). there is absolutely NO guarantee for any data smaller than 512 bytes to appear in file the same order you might have intended. If you really need this, there is no other way than to "do their own caching". Getting back to the original poster's question, "fprintf" is using "write" at _some_ point in time, exactly when it'll do depends on something like the associated buffer's size... HTH, cheers. l8er manfred