News for hackers. Stuff that matters.
Re:Making Sense of Acquire-Release Semantics by moonchild on Sunday May 12, 2024 @02:11PM (#40336316)
total order on all accesses to a given location—loads from a single location can't be reordered w.r.t. each other either

i don't remember seeing any wording relating to mixed-size accesses in the intel manual (not withstanding that the official models are ... ambiguous, to say the least, compared with what 3rd-party researchers have done)

Re:Making Sense of Acquire-Release Semantics by gpderetta on Sunday May 12, 2024 @02:17PM (#40336352)
For a total store order to be meaningful of course it implies that loads are also non visibly reordered. If a store falls in the forest but nobody is around to load it, was it really ordered :)
Re:Making Sense of Acquire-Release Semantics by moonchild on Sunday May 12, 2024 @10:00PM (#40339171)
Tbf you could say stores happen in order, and loads can happen out of order unless you fence. Personally I don't understand why we need such strong ordering constraints for weakly ordered reads—istm you can go much weaker and maintain sanity.
Re:Making Sense of Acquire-Release Semantics by gpderetta on Sunday May 12, 2024 @06:28PM (#40338054)
> i don't remember seeing any wording relating to mixed-size accesses in the intel manual (not withstanding that the official models are ... ambiguous, to say the least, compared with what 3rd-party researchers have done)

I was probably misremembering the details. The manual has to say this regarding #LOCK prefixed operations:

"Software should access semaphores (shared memory used for signalling between multiple processors) using identical addresses and operand lengths. For example, if one processor accesses a semaphore using a word access, other processors should not access the semaphore using a byte access"

which is already vague enough, but regarding general atomic load and stores I couldn't find anything.