Is write(2) "atomic" ?

[Chris Torek]

In article <3247 at phoenix.Princeton.EDU> haahr at phoenix.Princeton.EDU
(Paul Gluckauf Haahr) writes:
>worse than just mixing up data, if two processes are pounding away
>at a file, it data may be lost.  (see below)

This is due to a bug in 4.2BSD (and probably others).  Looking at
the 4.2BSD code, it seems to be that uio->uio_offset is not set
unless FAPPEND, instead relying on the value set before the ILOCK()
(all in /sys/sys/sys_inode.c ino_rw()).  Two `simultaneous' writes
will cause the second to block in ILOCK(); meanwhile, fp->f_offset
will grow from the first writer, without uio->uio_offset growing
for the second writer when the first finally unlocks the inode.

>some special file types may implement atomic writes.  notably, berkeley
>sockets (at least under SunOS 3.5 and Ultrix 2.0) appear, empirically,
>to be fully atomic.  this is probably to support "reliable" protocols
>like tcp/ip.

I am not sure whether this is by design; it is due to the FIFO
behaviour of sleep() (see /sys/sys/uipc_socket.c sosend(), where more
is being sent than fits: if SS_NBIO nonblocking i/o, EWOULDBLOCK or
short write, else unlock socket buffer and sleep on it).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris