Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.database
Subject: Re: locks
Message-ID: <5955@utzoo.UUCP>
Date: Fri, 13-Sep-85 13:16:32 EDT
Article-I.D.: utzoo.5955
Posted: Fri Sep 13 13:16:32 1985
Date-Received: Fri, 13-Sep-85 13:16:32 EDT
References: <10185@ucbvax.ARPA> <5909@utzoo.UUCP> <10233@ucbvax.ARPA>, <341@harvard.ARPA>
Organization: U of Toronto Zoology
Lines: 38

> 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