[Bug 1255] filesystem not thread-safe

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1255





--- Comment #2 from Chris Johns <chrisj at rtems.org>  2010-06-02 01:49:00 ---
There is a semaphore allocated with every file op but as far as I know never
used. It looks like part of this work has already been done.

The difficult part is concurrency model we want. For example the device IO
layer. Do we allow more than one reader into the driver and let the offset
become a mess or should we not allow this and enforce strict ordering of call ?
The standard for read states:

 "I/O is intended to be atomic to ordinary files and pipes
  and FIFOs. Atomic means that all the bytes from a single
  operation that started out together end up together, without
  interleaving from other I/O operations. It is a known
  attribute of terminals that this is not honored, and
  terminals are explicitly (and implicitly permanently)
  excepted, making the behavior unspecified. The behavior for
  other device types is also left unspecified, but the wording
  is intended to imply that future standards might choose to
  specify atomicity (or not)."

This means we should implement the locking on each IO operation. We can assume
the IOP is not active until open has returned. All libio allocator is
protected. We should let file system manage the locking and not the generic
layer. The current read call should be changed to let the file system handle
this and to remove the race condition from the generic layer. File systems like
the RFS already protect accesses at the file system layer and therefore handle
this so extra generic locking only lowers performance.

The standard says terminals are allowed to have concurrent IO. I am not sure
how we handle this. I assume this means reading and writing at the same time.
The same goes for sockets. Here we can read and write at the same time. Do we
let device IO exist with the race condition and document it ?

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.