home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 097 / text0000.txt < prev   
Encoding:
Internet Message Format  |  1990-12-05  |  1.4 KB
  1. From: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe)
  2.  
  3. In article <497@usenix.ORG>, swart@src.dec.com (Garret Swart) writes:
  4. > I believe in putting lots of interesting stuff in the file system name
  5. > space but I don't believe that semaphores belong there.  The reason
  6. > I don't want to put semaphores in the name space is the same reason
  7. > I don't want to put my program variables in the name space:  I want
  8. > to have lots of them, I want to create and destroy them very quickly
  9. > and I want to operate on them even more quickly.  In other words, the
  10. > granularity is wrong.
  11.  
  12. So why not choose a different granularity?  Have the thing that goes in
  13. the file system name space be an (extensible) *array* of semaphores.
  14. To specify a semaphore, one would use a (descriptor, index) pair.
  15. To create a semaphore in a semaphore group, just use it.
  16. If you want to have a semaphore associated with a data structure in
  17. mapped memory, just use a lock on the appropriate byte range of the
  18. mapped file.
  19.  
  20. (Am I hopelessly confused, or aren't advisory record locks *already*
  21. equivalent to binary semaphores?  Trying to lock a range of bytes in
  22. a file is just a multi-wait, no?  Why do we need two interfaces?  (I
  23. can see that two or more _implementations_ behind the interface might
  24. be a good idea, but that's another question.)
  25. -- 
  26. Heuer's Law:  Any feature is a bug unless it can be turned off.
  27.  
  28. Volume-Number: Volume 21, Number 97
  29.  
  30.