Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!sdcsvax!ucsdhub!hp-sdd!hplabs!hpda!athertn!ericb
From: ericb@athertn.Atherton.COM (Eric Black)
Newsgroups: comp.unix.wizards
Subject: Re: Unix vs. OS/2 (was RE: Pournelle on Unix)
Message-ID: <160@teak.athertn.Atherton.COM>
Date: 12 Jan 88 04:48:20 GMT
References: <11156@brl-adm.ARPA> <448@minya.UUCP>
Reply-To: ericb@teak.UUCP (Eric Black)
Organization: Atherton Technology, Sunnyvale, CA
Lines: 32

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.
                                                         ^^^^^
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.

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.  It's fun to explain this to people
who have a couple of windows up, one a remote login to another
machine which is also NFS-mounted on the local machine, and
have "ls" of the same directory show two different things!
-- 
Eric Black	"Garbage in, Gospel out"
   UUCP:	{sun!sunncal,hpda}!athertn!ericb
   Domainist:	ericb@Atherton.COM