home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / volume.17 / text0006.txt < prev    next >
Encoding:
Internet Message Format  |  1990-01-06  |  2.7 KB

  1. From: barry@PRC.Unisys.COM (Barry Traylor)
  2.  
  3.  
  4. Unfortunately, being a recent subscriber to usenet, I missed all but
  5. Donn Terry's followup on the discussion of File Handles.  
  6. Could the submitters (who happen to consider their submissions
  7. on the subject interesting) forward their articles to me.  
  8.  
  9. Within my development group there has been some debate about the file handle
  10. issue.  I believed the onus was on the implementation, but was convinced by
  11. associates, more imbued with the Unix tradition than myself, that that
  12. was not the case, that the onus was on the application.  Donn's followup
  13. leads me to believe that my first assumption was correct.  This unfotunately
  14. leads me to a degree of confusion and consternation.
  15.  
  16. My understanding, from reading the (extensive) verbiage in 1003.1, chapter 8, 
  17. is that the intent of the rules is to preserve a given "stream"'s view of the 
  18. file (behind a file description) given that there may be (possibly) conflicting
  19. usage of the file description by both other file descriptor I/O and other 
  20. "stream" I/O (of course eventually using file desriptors).  Am I correct in 
  21. this?  If I am correct, then I believe a race condition can occur between 
  22. uncoordinated streams using a file description with regard to underlying lseek 
  23. and read (or write) calls.  Given that stream I/O is almost always implemented 
  24. as a library, and that synchronization mechanisms (other than fcntl locking, 
  25. which I believe cannot be applied in this case, at least using the 
  26. open file description in question) and shared memory mechanisms (for cross task 
  27. usage) are not provided, it is not clear to me how the race condition can be 
  28. avoided by the interfaces provide in 1003.1.  I do realize, however, that
  29. such synchronization methods will be provided in 1003.4, but that the use
  30. of such might be (somewhat) painful in a library environment.
  31.  
  32. While the race can occur on a uniprocessor system that allows for the 
  33. interruption and rescheduling of processors to processes, this problem can
  34. become quite noticeable with multiprocessor systems.
  35.  
  36. Am I missing something here?  It seems clear to me that there is no way of
  37. avoiding the case where stream A (in process PA) does a lseek()/read() and
  38. stream B (in process PB) does an lseek()/read() to a different part of the 
  39. file, that lseek() A -> lseek() B -> read() A -> read() B, can be reliably 
  40. prevented, short of using fairly painful library-coordinated locking
  41. mechanism between the lseek()s and read()s.  I am now seriously considering
  42. implementing kernel rread() (random read) and rwrite() (random write) functions
  43. so as to avoid the race.
  44.  
  45. Barry Traylor
  46. Unisys Corp, A Series Engineering
  47. Paoli, Pa.
  48. e-mail:  barry@prc.unisys.com
  49.  
  50. Volume-Number: Volume 17, Number 9
  51.  
  52.  
  53.