Is a successful call to write(2) atomic?

Ronald F. Guilmette rfg at tristatelogic.com
Tue Jun 15 06:11:10 UTC 2021


OK, here's a stupid programming question.  I believed that I knew the
answer to this, but now I'm no longer so sure.

Assume that a given program, "example", forks a child process (or perhaps
many such) and then each of these processes tries, in a manner that is
entirely non-sychronized with any of the others, to write blocks of data
using calls to write(2) to file descriptor 1.

Assume further that "example" is run from the command line as follows:

     example > ordinary-disk-file

Lastly asume that the return value for all calls to write() is diligently
checked to insure that it is never either -1 or a short write count,
and that if it ever, is, "example" will exit with a non-zero exit status
(and assume also that otherwise it will exit with a zero exit status).

Question:  Assuming that "example" runs and exits with a zero status (thus
indicating that all calls to write() completed successfully and none returned
a short write count) then might it ever be the case that some single chunk
of data that was successfully written to "ordinary-disk-file" by a single
call to write() might be split into two or more parts in the output file,
with chunks of data that were written by other processes in the same family
possibly being interleaved between parts of that one chunk in the output
file?

In other words:  Is a block of data that is successfully written by a single
call to write() itself treated as being effectively atomic and indivisible,
i.e. with repsect to the physical output file?

I have always assumed so, but looking at the man page for write(2) just now
I see that it contains no such guarrantee.  And in fact, I have an output
file which was written to by multiple processes from a family or procsses,
and where some of the output appears to have been garbled in the sense of
text lines that I know were written by one process being muddled up with
lines that were written from other processes  from the same family.  Of
course, this -might- all just be down to my own crappy programming.  That's
what 'm tryiong to determine.)



More information about the freebsd-questions mailing list