Is a successful call to write(2) atomic?

Arthur Chance freebsd at
Wed Jun 16 13:17:42 UTC 2021

On 16/06/2021 01:09, Ronald F. Guilmette wrote:
> In message <CAFbbPugCir436Z6cHyOZBtRAQ0on0eFfYc0Z0xNrhHCRW3r=4A at>
> Paul Procacci <pprocacci at> wrote:
>> It now reads:
>> This volume of POSIX.1-2017 does not specify the behavior of concurrent
>> writes to a regular file from multiple threads, except that each write is
>> atomic (see *Thread Interactions with Regular File Operations*
>> <>).
>> Applications should use some form of concurrency control.
>> In both cases, it states:  "Applications should use some form of
>> concurrency control".
> Sigh.  The above (revised) verbage isn't my personal idea of unambiguous
> clarity.  I mean it isn't even clear what -they- mean by "atomic" in this
> context.  They may intend it to mean exactly what I have been using it
> to mean here, but if I have learned anything about Posix, it is that their
> documents are sometimes subtle in their use of terminology.  (I sustained
> some serious verbal abuse on one Posix mailing list some months ago for
> my failure to fully appreciate this.)

>From Posix documentation on write(2):

Atomic/non-atomic: A write is atomic if the whole amount written in one
operation is not interleaved with data from any other process.

However, only two cases are guaranteed to be atomic:

1) writes to a pipe/FIFO of <= PIPE_BUF bytes

See the beginning of the Rationale section of

2) writes to a regular file from different pthreads *within the same


Apart from the first case there is no requirement for atomic writes in
Posix when multiple processes are involved.

> More to the point, if indeed each call to write() *is* "atomic"... at least
> in the sense that the given buffer will be treated like an indivisable whole,
> all of the way along its journey to some physical device... then why are
> users nontheless being encouraged, still, to "use some form of concurrency
> control"?  I mean what would be the point of that if in fact write() never
> busts up the hunks of data given to it into separate sub-hunks?
> Sounds to me like they are saying "Here, we are giving you this belt, but
> we advise you to wear your suspenders also, just in case."

More like "we think the builders may have installed the floors in this
darkened building, but we suggest a flashlight and safety harness"

> This seems goofy on the face of it.

The problem is that when Posix first arrived it attempted to codify the
lowest common denominator of (then) existing Unix implementations and
has grown from that very low base.

Lebowskisort, aka dudesort, an O(1) sorting algorithm:

"Man, the array is cool as it is. Let's go bowling."

More information about the freebsd-questions mailing list