what's needed is a application barrier() call [LWN.net]

what's needed is a application barrier() call

Posted Sep 9, 2009 18:36 UTC (Wed) by quotemstr (subscriber, #45331)
In reply to: what's needed is a application barrier() call by dlang
Parent article: POSIX v. reality: A position on O_PONIES

rename ought to imply a barrier because there are no useful cases for a non-barrier rename, and plenty of cases for a rename-with-barrier. Forcing application authors to use a separate call will simply allow them to forget it, and will ensure that existing applications are still unsafe. A barrier-on-rename scheme adds safety with no loss in expressiveness, and is a performance increase over fsync, which is, well, synchronous.

(Log in to post comments)

what's needed is a application barrier() call

Posted Sep 9, 2009 19:06 UTC (Wed) by quotemstr (subscriber, #45331) [Link]

Ah, I see. fbarrier is an interest construct. You'd still need the rename trick in order to prevent observers from seeing inconsistent files at runtime. A program modifying /etc/passwd should prevent other applications from seeing an incompletely-written file. One could do this locks, but a simpler mechanism is rename.

what's needed is a application barrier() call

Posted Sep 9, 2009 20:55 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]

correct, barrier() would not be a replacement for rename(), rename could (and probably should) imply a barrier.

History (re: what's needed is a application barrier() call

Posted Sep 10, 2009 16:18 UTC (Thu) by davecb (subscriber, #1574) [Link]

Rename was one of the two Unix V6 system calls which were documented as being necessary and sufficient to allow one to do atomicity and locking: the other was open(... O_EXCL|O_CREAT). The latter atomically creates files, the former atomically changes them, including atomically making them cease to exist. I rather expect Thompson and Ritchie would be bemused by some of the discussion to date (;-)

--dave

History (re: what's needed is a application barrier() call

Posted Sep 10, 2009 20:18 UTC (Thu) by aegl (subscriber, #37581) [Link]

"Rename was one of the two Unix V6 system calls"

Nope. "rename" wasn't in V6 (see http://minnie.tuhs.org/UnixTree/V6/usr/sys/ken/sysent.c.html).

"the other was open(... O_EXCL|O_CREAT)"

V6 open(2) didn't have all those fancy O_* options. You just got the choice of FREAD, FWRITE, or both.

Applications in V6 era typically used "link(2)" as their locking primitive (create a randomly named tempfile, then link that to a statically named lockfile. If the link call succeeds, you own the lock. If you get EEXIST, then someone else does).

History (re: what's needed is a application barrier() call

Posted Sep 10, 2009 21:03 UTC (Thu) by davecb (subscriber, #1574) [Link]

Thanks! I used V6, but you are entirely correct,
the open/rename indeed come later.

--dave