🚀 go-pugleaf

>From DODDS@BBNA Mon Mar  1 15:08:38 1982
The problem mentioned by Arthur Keller certainly is the classic
one of access conflicts in shared databases.  We in the HERMES
group at BBN have been there before.

TENEX and its descendant TOPS-20 have never had a proper way of
locking a file for the use of one process without opening it and
keeping it open.  In HERMES we beat the problem to death by using
the companion file to the given message file (where parse
computations are stored for use in later sessions) as the
repository for interlock information.  We keep IT open, in order
to keep the message file itself closed as much as possible, to
receive mail.  The price of this has been periodic clobbered
companion files, due to system crashes with the file opened and
mapped in user space.

The HERMES scheme, worked out several years ago by Austin
Henderson and me, contains a number of elaborate features
directed at fine-grained shared access to a message file
(database).  The editor problem is a considerably simpler subset
of the database problem; in particular, one wants not to share
access to a file, safely, with other processes, but rather just
to lock other processes out of access until the first one is done
with its work.  Still, I think a similar consideration of the
premises and constraints of the problem is in order before
attempting to implement a scheme for an existing editor.

In particular, I want to emphasize the melancholy conclusion that
I had to accept in considering this business: due to a basic
design deficiency of the TENEX/TOPS-20 file system, there is no
complete way to interlock access to a file.  Any scheme
implemented in user software, no matter how careful, can only be
an incomplete approximation of the missing system ability.

If anybody is interested, I will be happy to write up an overview
of the considerations involved in the HERMES interlock design.

Doug Dodds <DODDS at BBNA>