Re: pwrite() and threads

[Giles Lean <giles.lean%pobox.com@localhost>]

Wouter Klouwen <dublet%acm.org@localhost> wrote:

> Depends. As far as I can tell, pwrite itself should be atomic, regardless
> how big the data buffer is. 

POSIX doesn't agree with you, I'm afraid.  The Rationale section
of the write() specification mentions the issue specifically
(pwrite() is defined largely in terms of a version of write()
which doesn't change the file position):

| Atomic/non-atomic: A write is atomic if the whole amount
| written in one operation is not interleaved with data from
| any other process. This is useful when there are multiple
| writers sending data to a single reader. Applications need
| to know how large a write request can be expected to be
| performed atomically. This maximum is called
| {PIPE_BUF}. This volume of IEEE Std 1003.1-2001 does not say
| whether write requests for more than {PIPE_BUF} bytes are
| atomic, but requires that writes of {PIPE_BUF} or fewer
| bytes shall be atomic.

So if you want non-interleaved writes:

a) write in smaller than PIPE_BUF amounts, or
b) trust to luck

I've found with computing that Murphy rules and would not
choose 'b' myself. :-)

> It seems to me that you need to lock before you calculate the offset anyway.
> If you are logging, why are you not opening these files in "a" mode and just
> using write() anyway?

You've still got the atomic issue with write().

So, yeah, either give up on multiple threads/processes
writing, keep below PIPE_BUF, or lock the file before writing
is all I can think of at the moment.

Giles