Skip site navigation (1)Skip section navigation (2)
Date:      25 Aug 1999 13:42:16 +0300
From:      Ville-Pertti Keinonen <will@iki.fi>
To:        wes@softweyr.com (Wes Peters)
Cc:        hackers@freebsd.org
Subject:   Re: Mandatory locking?
Message-ID:  <86pv0ccfau.fsf@not.demophon.com>
In-Reply-To: wes@softweyr.com's message of "25 Aug 1999 09:14:26 %2B0300"
References:  <19990823231130.A16133@netmonger.net> <37C3890B.7AD1E44F@softweyr.com>

next in thread | previous in thread | raw e-mail | index | archive | help

wes@softweyr.com (Wes Peters) writes:

> And how many programmers with nearly (or more than) two decades of UNIX
> experience it takes to convince someone it really is useful.

It should only take one, as long as the arguments made are not bogus.

IMHO Greg made some very silly arguments (or at least used some very
stupid examples) for mandatory locking and never answered my points
regarding them.  (The arguments of some of the ones opposing mandatory
locking have been equally silly.)

I *do* agree that mandatory locking *can* be useful, but the
usefulness is not nearly as broad as some people seem to be implying,
and advisory locking is not as useless as some claim.

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.

Locking entire files is also the only way to ensure that non-locking
programs can even see the file in a consistent state.

As a special case, mandatory locking could also be useful in ensuring
long-term exclusive access to some set of data, but this seems like
something that should be done using file permissions.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86pv0ccfau.fsf>