Andrew Lentvorski wrote:
First, if two machines write to nominated simultaneously, nominated can
get corrupted.
No.
You assume that the writing of nominated has atomic semantics.
Considering that's how it's documented, yes. Writing is atomic. It
either completes or fails.
You also
assume that nominated has a write barrier which guarantees the ordering
of the steps 1C and 1D.
No I don't. You write something in there. Then you watch for it to
change, until everyone else has agreed with what's in there. You're
missing that 1D is part of the loop, while 1C only runs once. 1B skips
1C if the Nom file already exists.
You also assume the writes have a known fixed
ordering on all machines. It is possible for the following sequence to
occur:
Machine A Machine B
Write A to Nom Write B to Nom
Write B to Nom Write A to Nom
Machine A never writes B to Nom. Where do you see that?
Machine B never writes A to Nom. Where do you see that?
The second row here never happens. Nobody every writes anything to NOM
except their own name. Nobody writes to NOM more than once. That's part
of the trick to making sure it works without locking.
Read Nom-See B Read Nom-See A
Nothing prevents this without locking.
That would be correct, if that were how it works.
Obviously, test-and-set is easier when you're talking about local
memory and stuff. But there's no test-and-set over (say) NFS, and
hence locking is messy there.
Quit spouting wrong information! Please go read NFS Illustrated. NFS
locking works *JUST FINE*. Only flock() in Linux sucks,
OK. I was just going on what my sysadmin and my own tests showed. I
agree my information may be out of date.
Let me rephrase, then. It's a good technique to know for all the
situations where remote file systems, like older versions of NFS, don't
do the right thing w.r.t. locking.
--
Darren New / San Diego, CA, USA (PST)
His kernel fu is strong.
He studied at the Shao Linux Temple.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
