Is the write(2) system call atomic

[gaf at blu.org (Jerry Feldman)]

On Sat, 8 Apr 2006 12:50:52 -0400 (EDT)
markw at mohawksoft.com wrote:

> I hacked up your code to see if I could reproduce the problem. I have a
> couple SMP Linux boxes as well as some SMP FreeBSD 6 boxes.
> 
> I could not get your results.
> 
> However, you shouldn't get the overwrite issues. As I understand it, there
> is only one file descriptor in the kernel per physical file. Also, every
> database in the world would fail on Linux.
> 
> I suspect that there is more to this problem than your example gives (Your
> example could not have produced the expected results). If one of the
> processes were using seek(), or if the file was opened with "fopen()" that
> may explain it.
His original code used fopen et. al, but his updated example used only
file descriptors and open(2), write(2), close(2). 
I also sent you a list of systems I tested on. 
The ones that fail are multi-processor systems (both SLES9 and RHEL 4)
using both AMD and Intel chips. Those systems are made publicly 
available by HP (http://www.testdrive.com). All you need to do is to
register. You will get an account, and you can log into a number of
different systems (http://www.testdrive.hp.com/current.shtml).

The problem is that write(2) to a file is NOT atomic. On a
multi-processor system you have true parallelism. One solution is to
use lockf(3) or fcntl(2) as a lock. (The lseek approach is not a
solution as it will fail on some conditions which I found out years ago
with the utmp library functions).  Note that flock(2) will fail on NFS.

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20060408/87872be2/attachment.sig>