Path: utzoo!attcan!uunet!husc6!purdue!umd5!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.unix.wizards Subject: Re: Is write(2) "atomic" ? Message-ID: <12434@mimsy.UUCP> Date: 12 Jul 88 23:32:41 GMT References: <11410005@eecs.nwu.edu> <3247@phoenix.Princeton.EDU> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 25 In article <3247@phoenix.Princeton.EDU> haahr@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@mimsy.umd.edu Path: uunet!mimsy!chris