🚀 go-pugleaf

> The best thing to do
> would be to provide a simple, easy to use, efficient, lock mechanism
> in the operating system... [for use in implementing the desired scheme]

No argument.

> VMS (no flames please) has such a lock manager.

Unix has a file system, which can be used for the same thing.

> The idea is that locks are named when they are created.

Files are named when they are created.

> There are primities to lock, unlock, and wait on locks.

There are primitives to link and unlink files.  There is no easy way to
wait, which is a serious blemish.

> All that is required is that users agree on a
> naming scheme for the locks.

I.e., for the files.

Simple?  Yes, except for the wait problem.  Easy to use?  Yes, except
for the wait problem.  Efficient?  Not outstandingly, but *this* can
be addressed without inventing any new semantics (except for the w.p.);
it's easy enough to create a driver for a little filesystem that lives
in main memory, eliminating disk overhead.  Even the wait problem can
be licked if you have named pipes (aka fifos):  read-one-byte and write-
one-byte become lock+wait and unlock, although you need the clumsy and
ugly non-blocking read to get a non-blocking-lock-attempt operation.

In short, don't re-invent the wheel if the one you've got is already
almost round enough.  Round off the existing one instead.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry