> I know FOR A FACT the answer to my above question about ordering of all reads vs all writes is not the same for x86, Apple's TSO, NVIDIA's TSO, and Fujitsu's TSO.

Well of course they differ. TSO says that some reorderings are banned and some are optional, and there's a million factors that go into deciding when those options are taken.

> "TSO" is three letters. It is not a spec.

It's a few rules that you can depend on. Are those rules not enough to build a program on top of? The simpler you make your rules, the less spec you need. On the other end of the spectrum, a dozen specialized memory barriers need a ton of explanation.

▲

dmitrygr a day ago | parent [-]

>> "TSO" is three letters. It is not a spec.

>It's a few rules that you can depend on.

Until properly specified they are not "rules" but "hopes". Apple made no promises and provided no specs for their TSO mode. What makes you sure that that TSO bit on AppleM4pro acts the same as on AppleM1? That same "TSO" bit might mean yet a third thing on AppleM7megaMaxProEliteG2 in 2031. How do you know that an OS update that also updated iBoot on your Mac did not change some internal chip config MSR and now even on your AppleM4pro CPU whose TSO you understood, it acts differently due to this config bit change?

▲

Dylan16807 a day ago | parent [-]

I wasn't talking about Apple's promises, I was talking about the meaning of "TSO". If you know you have TSO, you have some rules you can depend on. What's an example of something you need beyond those rules, to write correctly concurrent code?

▲

dmitrygr a day ago | parent [-]

> If you know you have TSO

"If you know you have world peace"

Sure, now define "total". Which accesses does that affect and which ones does it not? Is device memory included? PCIe memory? Are there ordering guarantees between mappings with different permissions?

Then, define "store ordering". Does it affect loads in any way? Or simply just stores?

▲

Dylan16807 a day ago | parent | next [-]

> Sure, now define "total". Which accesses does that affect and which ones does it not? Is device memory included? PCIe memory? Are there ordering guarantees between mappings with different permissions?

At a basic level TSO is a model for how cores interact and devices are weird, so I'd say those get to be unspecified.

And ideally you want a line saying if the instruction cache needs to be flushed for self-modifying code since that's kind of a violation if not specified but it's a forgivable one.

> Then, define "store ordering".

Sure, though I'm not promising my wording is perfect: In TSO, when stores complete they become visible to all other cores and all cores agree on the exact same list of completed stores.

> Does it affect loads in any way? Or simply just stores?

Depends on what you mean by "affects". Loads in one core might not see stores from another core that have not yet reached the global/total list.

▲

slabtickler a day ago | parent | next [-]

just speaking honestly i would not consider I$ snooping as part of the definition of TSO. it is part of the x86 memory model yes but “TSO” does not define the full story here

▲

dmitrygr a day ago | parent | prev [-]

> when stores complete they become visible to all other cores and all cores agree on the exact same list of completed stores.

Not that they agree on what completed but on the order they completed in. That is the "o" in TSO. You inadvertently proved my point.

> so I'd say those get to be unspecified.

* CRASH *

You left something unspecified that mattered. Ordering of accesses to mappings with differing permissions matters, and whether they are seen in-program-order or not by other cores will break x86 emulators (main use cases for TSO).

That's the point here :) This is the usual "i am sure we can all agree what X means" argument - it does not work when it comes to precise things like memory models.

	▲	Dylan16807 a day ago \| parent [-]
		> Not that they agree on what completed but on the order they completed in. That is the "o" in TSO. You inadvertently proved my point. A list is ordered. You're trying too hard to nitpick. (Also I gave a disclaimer that my wording wasn't perfect, and it only took a couple words for you to "fix" it. If it can be fixed that easily then that doesn't actually counteract my point.) > You left something unspecified that mattered. Ordering of accesses to mappings with differing permissions matters, and whether they are seen in-program-order or not by other cores will break x86 emulators (main use cases for TSO). How many x86 emulators have the emulated code talking directly to hardware, to the same piece of hardware, from multiple cores at the same time? I don't think this is a "main use case". Plus there's going to be a baseline for how talking to the hardware works. Only TSO-mode-specific details of the hardware access are left unsaid in this basic model, and many access patterns fitting the above description still won't notice anything one way or the other.

▲

gpderetta 18 hours ago | parent | prev [-]

> define "store ordering". Does it affect loads in any way? Or simply just stores

It affects the visible ordering of remote stores to normal memory, so load are necessarily affected (it wouldn't make sense to guarantee a store order if unobservable).

Really, TSO is defined independently of x86 and in fact it took a while to actually prove that x86 was TSO. Concretely, how do architectures that claim (optional) TSO differ from each other at least for access to normal memory?