On Fri, Jun 14, 2019 at 06:01:07PM -1000, Linus Torvalds wrote: > On Thu, Jun 13, 2019 at 5:08 PM Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > I do not believe that posix itself actually requires that at all, > > although extended standards may. > > So I tried to see if I could find what this perhaps alludes to. > > And I suspect it's not in the read/write thing, but the pthreads side > talks about atomicity. > > Interesting, but I doubt if that's actually really intentional, since > the non-thread read/write behavior specifically seems to avoid the > whole concurrency issue. The wording of posix changes every time they release a new version of the standard, and it's _never_ obvious what behaviour the standard is actually meant to define. They are always written with sufficient ambiguity and wiggle room that they could mean _anything_. The POSIX 2017.1 standard you quoted is quite different to older versions, but it's no less ambiguous... > The pthreads atomicity thing seems to be about not splitting up IO and > doing it in chunks when you have m:n threading models, but can be > (mis-)construed to have threads given higher atomicity guarantees than > processes. Right, but regardless of the spec we have to consider that the behaviour of XFS comes from it's Irix heritage (actually from EFS, the predecessor of XFS from the late 1980s). i.e. the IO exclusion model dates to long before POSIX had anything to say about pthreads, and it's wording about atomicity could only refer to to multi-process interactions. These days, however, is the unfortunate reality of a long tail of applications developed on other Unix systems under older POSIX specifications that are still being ported to and deployed on Linux. Hence the completely ambiguous behaviours defined in the older specs are still just as important these days as the completely ambiguous behaviours defined in the new specifications. :/ Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
