Standards Update, IEEE 1003.4: Real-time Extensions

[Richard A. O'Keefe]

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

In article <497 at usenix.ORG>, swart at 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