Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rtech.ARPA
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!hplabs!amdahl!rtech!jeff
From: jeff@rtech.ARPA (Jeff Lichtman)
Newsgroups: net.arch
Subject: Re: RMS v/s UNIX (non-religious)
Message-ID: <227@rtech.ARPA>
Date: Mon, 11-Mar-85 02:30:08 EST
Article-I.D.: rtech.227
Posted: Mon Mar 11 02:30:08 1985
Date-Received: Thu, 14-Mar-85 05:44:51 EST
References: <917@sjuvax.UUCP> <538@rlgvax.UUCP>, <2799@dartvax.UUCP> <5178@utzoo.UUCP> <23048@lanl.ARPA>
Organization: Relational Technology, Berkeley CA
Lines: 31

> > 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.
> 
> J. Giles

Read locks are very important in transaction systems.  If a process is allowed
to read a write-locked object, then it's possible for it to read data that will
later be backed out.  This could happen if the writer terminates abnormally,
or it deliberately orders a roll-back.  For example, suppose that one program
was performing an audit, and another was updating accounts.  If the updater
updated an account and then later rolled back this update, the reader could
get an invalid view of the update.

Also, if the writer has to make multiple updates to make the data consistent
(e.g. deducting from one account and crediting another), a reader could get
an inconsistent view of the data by reading only part of the updates.

My feeling is that the default should always be to prevent disaster.  If the
user wants to take the chance of inconsistency, or knows how to write programs
and schedule jobs to prevent inconsistency, then he or she should have the
option of relaxing the default.  A user shouldn't have to make a concious
decision to prevent disaster.
-- 
Jeff Lichtman at rtech (Relational Technology, Inc.)
aka Swazoo Koolak