Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!bu-cs!bzs
From: bzs@bu-cs.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Is write(2) "atomic" ?
Message-ID: <23801@bu-cs.BU.EDU>
Date: 12 Jul 88 17:08:00 GMT
References: <11410005@eecs.nwu.edu>
Organization: Boston U. Comp. Sci.
Lines: 33
In-reply-to: naim@eecs.nwu.edu's message of 12 Jul 88 10:12:23 GMT


>Do UNIX semantics guarantee that write(2) calls will be "atomic" ?
>
>Suppose, process A executes write(fd, "123", 3) and process B
>executes write(fd, "456", 3) "concurrently". The file descriptor fd
>is shared between them (the file was creat(2)'ed for writing by the
>common parent of A and B). Does UNIX guarantee that the contents of
>the descriptor will be "123456" or "456123" (depending on which of
>A and B won the race) but never "124536" ? Does it make a difference
>whether the descriptor is a pipe or a terminal or a disk file or a
>tape drive or something else ?
>
>		      Naim Abdullah

There's another possibility which is hard to illustrate but more like
write(fd,"123456",6) and write(fd,"ABC",3) -> "123ABC456" (what I'm
trying to say is atomic in units of some page size or block boundary)
and yet another (infra vide.)

I think the result is indeterminate (undefined), a few experiments
here on various systems came up with some even stranger results than
the above (as if the file was just overwritten, more like "123ABC" for
the [expected] 9-char example above.)

Note to experimenters: try it with one buffer (single write) very
large, like 100K or more. With smallish buffers things tend to
serialize.

Anyhow, that's what file/record locking is all about (NFS seemed to
strictly serialize things, however, I'm not sure if that's guaranteed
at all but I can see how it is more likely, just luck probably?)

	-Barry Shein, Boston University