Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.questions
Subject: Re: Are terminal writes atomic?
Message-ID: <19972@mimsy.UUCP>
Date: 4 Oct 89 08:18:41 GMT
References: <-286379999@hpcupt1.HP.COM> <1118@cs.yale.edu> <186@promark.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 31

In article <186@promark.UUCP> mark@promark.UUCP (Mark J. DeFilippis) writes:
>How about we take this further.  The answer to this question is an
>undocumented feature of write() under Unix.  Several Authors note
>that write() is atomic under Unix and that it is undocumented.
>One is Marc J. Rochkind in his book _Advanced Unix Programming_,
>Prentice-Hall.  Writes are Atomic, no matter what you are writing to,
>even terminals.

Of course, it might be undocumented because it is false.

On Berkeley systems (4BSD, at least), writes to character devices are
not locked at the syscall level, and hence could be reentered if the
driver (cdevsw[].d_write) function sleeps.  Tty writes all go through
`ttwrite()', which has two ways of sleeping: if the tty output queue
is over the `high water' mark, or if the machine runs out of clist
blocks.

The sleep queues are priority-FIFO, so if two processes sleep for the
same reason, the first one wins when a wakeup() happens (since they are
sleeping at the same priority).  But if one sleeps on lbolt while
another is sleeping on outq/high-water-mark (if this condition is even
possible), they might wake up in the `wrong' order and intermix
output.

Anyway, I am not going to try to figure out whether it never happens,
just remark that it is at least theoretically possible.  `If it ain't
documented, don't trust it'.  (Of course even if it is documented,
you might do well not to trust it anyway.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris