Path: utzoo!utgpu!water!watmath!clyde!ima!minya!jc
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.unix.wizards
Subject: Re: Unix vs. OS/2 (was RE: Pournelle on Unix)
Summary: Hey, I didn't write that!
Message-ID: <450@minya.UUCP>
Date: 14 Jan 88 01:55:18 GMT
References: <11156@brl-adm.ARPA> <448@minya.UUCP> <160@teak.athertn.Atherton.COM>
Organization: home
Lines: 53

In article <160@teak.athertn.Atherton.COM>, ericb@athertn.Atherton.COM (Eric Black) writes:
> In article <448@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
> >In article <11156@brl-adm.ARPA>, GUTHERY%ASC%sdr.slb.com@RELAY.CS.NET (guthery%asc@sdr.slb.com) writes:
> >> 	- systemwide semaphores
> >I'll let the other wizards hack apart the rest of the items on 
> >the list; I'll just point out that every Unix I've ever seen has 
> >systemwide semaphores.  They just aren't called that.  Try:
> >	if ((l = creat("/usr/spool/locks/<somename>",0)) {
> >		...
> >		[Critical section]
> >		...
> >		unlink("/usr/spool/locks/<somename>");
> >	} else {
> >		[Didn't get semaphore]
> >	}
> >It worked on BRL Version 6, and it still works, even on SunOS.
>                                                          ^^^^^
Hey, wait just a minute here; I didn't mention SunOS in my original posting;
I said Sys5 and BSD.  I wonder how I got misquoted?  I have seen some things
from people who said they tried it on their Foonix system and it works, so
maybe some of the postings got jumbled together.  Oh, well, it's not a real
big deal, and lets us get into a session of Sun-bashing. (;-)

> Careful in an NFS environment!  It doesn't work (where "work" is defined
> as "guarantees exclusive acquisition of the lock").
>
> This is why Sun had to add the lock daemon.

Yeah, in fact, Sun admits that NFS violates Unix file-system semantics
in numerous ways.  They say so in their manuals.  Unfortunately, some
of the things they don't implement are the things that you need in a
distributed environment even more than on a single processor.  Atomic
reads, writes and file creation are among the most important.  And
they're not even all that hard to do right.  You just have to avoid
the temptation to speed things up by caching the same block in more
than one place.

> You can see some obscure breakages in code which assumes that
> this time-honored technique will always work, when that code
> is run on machines accessing the directory containing the lock
> file across an NFS mount.  

The mistake is in porting code that depends on a Unix run-time 
environment to a non-Unix system (like SunOS).   File-system
stuff is a classical source of subtle problems, and when you
go from Unix to SunOS, you have the worst possible case of a
system which looks very familiar, but...

(Of course, when Sun and AT&T produce their merged OS, it will
be like Unix but will no longer support atomic I/O.  :-)

-- 
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)