henry@utzoo.UUCP (Henry Spencer) (09/18/85)
On cleaning out my archives, I ran across the following message which is
of some relevance to the current discussion:
-----
From watmath!clyde!bonnie!akgua!gatech!seismo!mo Thu Mar 14 16:43:41 1985
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 2/19/85; site seismo.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!gatech!seismo!mo
From: mo@seismo.UUCP (Mike O'Dell)
Newsgroups: net.arch
Subject: Locking, again
Message-ID: <1685@seismo.UUCP>
Date: Wed, 13-Mar-85 09:09:02 EST
Article-I.D.: seismo.1685
Posted: Wed Mar 13 09:09:02 1985
Date-Received: Thu, 14-Mar-85 05:45:54 EST
Organization: Center for Seismic Studies, Arlington, VA
Lines: 50
This locking business is another Undead Topic, but here goes my part.
(1) General Petri nets have been shown to be insufficient to represent
all syncronizing problems, and a more powerful formalism has not been
put forward to my knowledge. This means WE CAN'T REALLY SOLVE THE
PROBLEM, so we are reduce to Engineering Solutions which solve some
useful subset.
(2) One of the most difficult issues is what people expect locks to mean.
In particular, when a process dies some horrid death while holding a lock,
(segmentation violation, inadvertent gunning-down by an aberant operator),
what should happen? If the lock means a simple append was being done,
they breaking the lock is probably OK, if not desirable. But if the
lock means "the database b-tree is inconsistant", then breaking the lock is
the last thing you want to do. Moreover, in the latter case, such
information should survive across system crashes if it to be of any use
whatsoever. So, now we have quickly gotten from "simple file locking"
to a stable, surviving lock which must be done with multi-phase commits,
not to mention what happens across networks.
So what does this mean?? It mean that concurrency control is an END-TO-END
issue just like communications error control, and you CANNOT put a single
mechanism into a system which will do the Right Thing all the time.
People who want to update a simple file can use advisory file locks just
fine without needing the hair of byte-span locks, although the byte-span
lock might provide more concurrency - since we have an implementation,
it is probably OK to use it. But people MUST understand what is NOT
promised by locks!! This is all the more reason to make them discressionary.
A non-discressionary lock is honored by all processes without their agreement,
while discressionary locks are honored only by "consenting processes".
This is VERY important where denial of service is considered a serious
security issue. Locking /etc/password, /bin, your enemy's home directory
or some other well-chosen target would bring a system to its knees in
an instant, or reduce it to a battlefield. This brings up the next point.
Protection is tricky in a locking environment. Who has the authority to
prevent someone from reading or writing a file they would otherwise
have permission operate upon?? To handle this anywhere close to right in
the presence of non-discressionary locks requires adding several if not
many more protection bits and thoroughly complicating the model.
I claim this complexity buys nothing useful and merely makes things more
complicated, particularly in distributed systems.
Well, enough of this for now. Locking is like the Camel sticking its
nose through the tent flap - before you know it, the Camel is in the
tent with you. The trip from "simple file locking" to "stable storage"
is beguilingly straight-forward to imagine, and damnably difficult
to realize, not to mention the question of whether you even want that.
-Mike O'Dell
-----
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry