g...@lemis.com (Greg Lehey) writes:
> All systems which do more than one thing at a time need file locking
> at some time or another. Since it involves cooperation between
> potentially unrelated processes, it's an obvious kernel function. Any
> "solution" requiring cooperation between processes isn't really a
> solution. As a result, I don't consider advisory locking to be real
> locking: it's just a kludge.
But strict explicit locks (I'll avoid the term "mandatory" to avoid
confusion) are only better than advisory locks in some restricted
cases.
You haven't commented on my previous critiques here. Nobody has
disputed them, other than by saying that mandatory locking does not
mean locking where you have to actually call a function to apply the
lock, but that doesn't appear to be what *you* mean by mandatory
locking.
As the most explicit critique was not Cc'd to you (I lose fields
because I read mailing lists through list->news gateways), and you may
have missed it in all of the noise on the list, so I'll quote myself
here:
The most significant advantage I see with mandatory locking over
advisory locking is guaranteeing atomicity for things done by
programs that do use locking. This only protects the data when
programs that access the same data without locking don't need
locking, which generally means that they either don't need to
modify the data or that there can't be multiple instances of those
other programs *and* the modifications made are themselves atomic
(can't be read-modify-write, or even multiple writes if
consistency is required).
This is a somewhat limited set of cases. If anyone can come up
with a counter-example, please present it.
Locking entire files, in addition to ranges, would seem to me to
be of further benefit, as it would allow properly locking programs
to fully protect against any single non-locking program which,
like Greg's cat example, would presumably be run interactively and
thus would require explicit stupidity to create additional races.
Note that protection is *at best* against a single program and at
worst only against other cooperative programs, as with advisory locks.
I can understand the aesthetic point of preferring that when you say
"lock the file", other processes don't get to do things to the file,
but the practical value of being able to do this is not *that*
significant, since the use of any non-cooperative programs makes
advisory and explicit locks equally useless with the exception of
cases mentioned above.
> FreeBSD is one of the few operating systems which doesn't have
> kernel-level locking. If we want to emulate other systems correctly,
> we *must* have advisory locking. This includes SCO UNIX, System V.4
How is FreeBSD's flock/fcntl advisory locking not kernel-level
locking?
> All this doesn't leave too much room for arguments about whether
> locking works or not: it works on all platforms except FreeBSD, and
> that's only because FreeBSD doesn't implement locking.
FreeBSD implements advisory locking. I would expect most people to
consider it locking. It's sufficient for a lot of things. There are
cases where some other kind of locking would be better, but then you
may say that any voluntary locking scheme is useless.
> - System V style. We need this for compatibility with System V. The
> choice of mandatory or advisory locking depends on the file
> permissions.
> - Only mandatory locking. fcntl works as before, but locks are
> always mandatory, not advisory. I'm sure that this won't be
> popular, at least initially, but if you don't like it, you don't
> have to use it.y
Perhaps both of the above, all with on/off sysctls. I would suggest
implementing both range and file locking.
Implementing mandatory locking as Terry Lambert defines it might also
be worth considering, but it shouldn't be made easy to turn on by
accident.
And for all additions, things should be properly documented, since
they might not guarantee what people would expect them to.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
