Date: Wed, 16 Jun 2021 14:17:23 +0100 From: Arthur Chance <freebsd@qeng-ho.org> To: "Ronald F. Guilmette" <rfg@tristatelogic.com>, freeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: Is a successful call to write(2) atomic? Message-ID: <7801a6e8-2428-619e-5722-7317841595a1@qeng-ho.org> In-Reply-To: <26258.1623802141@segfault.tristatelogic.com> References: <26258.1623802141@segfault.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16/06/2021 01:09, Ronald F. Guilmette wrote: > In message <CAFbbPugCir436Z6cHyOZBtRAQ0on0eFfYc0Z0xNrhHCRW3r=4A@mail.gmail.com> > Paul Procacci <pprocacci@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.) >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 https://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html 2) writes to a regular file from different pthreads *within the same process* See https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_07 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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7801a6e8-2428-619e-5722-7317841595a1>