low-end persistence strategies?

[Paul Rubin]

"Michele Simionato" <michele.simionato at gmail.com> writes:
> Ok, I have yet another question: what is the difference between
> fcntl.lockf and fcntl.flock? The man page of my Linux system says
> that flock is implemented independently of fcntl, however it does
> not say if I should use it in preference over fcntl or not.

It looks to me like flock is 4.2-BSD-style locking and fcntl.lockf is
Sys V style.  I'm not sure exactly what the differences are, but
generally speaking, BSD did this type of thing better than Sys V.  On
the other hand, it looks like lockf has more features, like the
ability to ask for a SIGIO notification if someone tries opening a
file that you have locked.  In Python, flock is certainly easier to
use, since you pass an integer mode flag instead of building up the
weird fcntl structure.

There's one subtlety, which is that I'm not sure locking your file
before updating it is guaranteed to do the right thing.  You may have
to use a second file as a lock.  E.g., suppose the data file is small,
like a few dozen bytes.  So maybe:
  1) process A opens the file.  The contents get read into a cache buffer.
  2) Process B opens the file, locks it, updates it, releases the lock.
  3) Process A locks and updates the file.  Is the cached stuff guaranteed
     to get invalidated even in some awful RFS environment?  Or could
     A clobber B's changes?