home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Usenet 1994 January
/
usenetsourcesnewsgroupsinfomagicjanuary1994.iso
/
sources
/
std_unix
/
v21
/
097
< prev
next >
Wrap
Internet Message Format
|
1990-12-05
|
2KB
From std-unix-request@uunet.uu.net Tue Sep 11 14:23:32 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
id AA16907; Tue, 11 Sep 90 14:23:32 -0400
Posted-Date: 11 Sep 90 07:06:23 GMT
Received: by cs.utexas.edu (5.64/1.76)
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>
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
X-Submissions: std-unix@uunet.uu.net
Date: 11 Sep 90 07:06:23 GMT
Reply-To: std-unix@uunet.uu.net
To: 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