Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site lanl.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!panda!talcott!harvard!seismo!cmcl2!lanl!jlg
From: jlg@lanl.ARPA
Newsgroups: net.arch
Subject: Re: RMS v/s UNIX (non-religious)
Message-ID: <23048@lanl.ARPA>
Date: Fri, 8-Mar-85 16:00:52 EST
Article-I.D.: lanl.23048
Posted: Fri Mar  8 16:00:52 1985
Date-Received: Mon, 11-Mar-85 05:37:06 EST
References: <917@sjuvax.UUCP> <538@rlgvax.UUCP>, <2799@dartvax.UUCP> <5178@utzoo.UUCP>
Sender: newsreader@lanl.ARPA
Organization: Los Alamos National Laboratory
Lines: 35

> As a miniumum, by default if one process has a file open with write
> permission no other process should be able to read or write that file.


The restriction should be that any process can read ANY shared file.  The
only constraint is that two processes shouldn't be writing to the same file
at the same time.  Read locks are only present in some systems because some
people like to use them as process synchronisation flags.  For example,
suppose I am trying to read a file that some other process is writing.  If
my process is ahead of the producer process, I will simply be reading old
data (until the end of file, then I will be forced to wait until the
producer catches up anyway).  But I should EXPECT to read old data if I'm
ahead of the producer (if the processes are really asynchronous I may be
unaware that the producer is presently running).  So a read lock would only
serve to synchronize the two processes - which should be done directly
anyway.

In the above argument I assume that record transfers are atomic operations
in the O/S (that is, the contents of a partially written record cannot be
read).  If this is not the case, problems will develop with or without read
locks.  Remember, people will ask for the specific ability to override any
automatically applied locks.

Someone made the claim that there are some issues pertaining to locks that
UNIX could not do at all even with libraries.  This is clearly not true
since VAX-UNIX can simulate a general Turing machine and can therefore
perform ANY computable function.  Clearly all that's required is for
processes that share file resources to do all I/O through a third 'monitor'
process which envokes your locking scheme.  In fact, each shared resource
could have its own monitor process associated with it.  This means more
overhead for those who wish to share file resources, but it means less
overhead for those who don't (as compared to a system which implements
locks at a lower level).

J. Giles