Is a successful call to write(2) atomic?

Ronald F. Guilmette rfg at tristatelogic.com
Wed Jun 16 00:09:03 UTC 2021


In message <CAFbbPugCir436Z6cHyOZBtRAQ0on0eFfYc0Z0xNrhHCRW3r=4A at mail.gmail.com>
Paul Procacci <pprocacci at gmail.com> 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*
><https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_07>).
>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.)

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."

This seems goofy on the face of it.


Regards,
rfg


P.s.  Thanks Paul, for researching the relevant Posix pronouncements.


More information about the freebsd-questions mailing list