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