Path: utzoo!utgpu!watserv1!watmath!att!occrsh!uokmax!apple!julius.cs.uiuc.edu!wuarchive!uunet!usenix!jsq
From: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-ID: <503@usenix.ORG>
Date: 11 Sep 90 07:06:23 GMT
References: <481@usenix.ORG> <495@usenix.ORG> <488@usenix.ORG> <491@usenix.ORG> <497@usenix.ORG> <497@usenix.ORG>,
Sender: jsq@usenix.ORG
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 28
Approved: jsq@usenix.org (Moderator, John Quarterman)
X-Submissions: std-unix@uunet.uu.net

From: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe)

In article <497@usenix.ORG>, swart@src.dec.com (Garret Swart) writes:
> I believe in putting lots of interesting stuff in the file system name
> space but I don't believe that semaphores belong there.  The reason
> I don't want to put semaphores in the name space is the same reason
> I don't want to put my program variables in the name space:  I want
> to have lots of them, I want to create and destroy them very quickly
> and I want to operate on them even more quickly.  In other words, the
> granularity is wrong.

So why not choose a different granularity?  Have the thing that goes in
the file system name space be an (extensible) *array* of semaphores.
To specify a semaphore, one would use a (descriptor, index) pair.
To create a semaphore in a semaphore group, just use it.
If you want to have a semaphore associated with a data structure in
mapped memory, just use a lock on the appropriate byte range of the
mapped file.

(Am I hopelessly confused, or aren't advisory record locks *already*
equivalent to binary semaphores?  Trying to lock a range of bytes in
a file is just a multi-wait, no?  Why do we need two interfaces?  (I
can see that two or more _implementations_ behind the interface might
be a good idea, but that's another question.)
-- 
Heuer's Law:  Any feature is a bug unless it can be turned off.

Volume-Number: Volume 21, Number 97