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