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

what's needed is a application barrier() call

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

I am not claiming that rename should not imply a barrier.

I am stating that rename should not be necessary to create a barrier.

don't require application writers to add renames if they wouldn't otherwise need them just because they want a barrier.

(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