On Thu, 2005-03-03 at 23:09, Darrin B.Jewell wrote:
> Chuck Silvers <chuq@chuq.com> writes:
> > POSIX requires that for regular files, read() and write() be atomic with
> > respect to each other (and write()s with respect to other write()s),
> > so we do need to keep enough locking to provide that.  however, there no
> > requirement that non-overlapping write()s be serialized, so tracking
> > the ranges are being read or written allows greater concurrency than
> > the current scheme of just tracking read vs. write.
> 
> Thanks for pointing this out.  I was not aware of a requirement in this
> area.  However, after your assertion, and yamt's comment, I looked it
> up in the online opengroup spec 6.  I found this in the rationale to the
> read() call found at:
> http://www.opengroup.org/onlinepubs/009695399/functions/read.html
> 
>   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)
> 
> Darrin

I know that some implementations of B (link) trees depend on this
feature to avoid locking the tree for read operations.

Stephan