Travis (travis.downs.delete@this.gmail.com) on April 12, 2017 11:33 am wrote:
> Michael S (already5chosen.delete@this.yahoo.com) on April 11, 2017 2:32 pm wrote:
> > anon.1 (abc.delete@this.def.com) on April 11, 2017 9:03 am wrote:
> > > x86 memory ordering is TSO (or almost), isn't it? All stores
> > > need to be seen in the same order across all cores
> >
> >
> > More so, both almost TSO and almost SC.
>
> As far as I know it is fully TSO, at least how that term has always been defined. AFAIK TSO pretty
> much just formalizes the hardware behavior when stores all go to memory in FIFO order, and you have
> (the usual) cache coherence that makes all stores show in the same order for everyone.

Probably. SPARC manuals do not appear too detailed about it. Or, may be, I never had enough of motivation to follow them with the necessary level of attention.

>
> Yes, you can locally see a store out of order due to write
> buffers, but that has always been allowed in TSO, AFAIK.
>
> Put another way, you can think of the four possible reorderings, LoadLoad, StoreLoad,
> LoadStore and StoreStore (in terms of the old SPARC barriers). TSO basically means that
> all of them are no-ops except StoreLoad. If you made StoreLoad also a no-op, you'd just
> have SC. So x86 is completely TSO and "almost SC" in that TSO is almost SC.
>
> Of course, almost SC doesn't help you much for say lock-free programming, since the StoreLoad
> reordering comes up in practically every algorithm. So you are generally not getting full barrier-free
> implementations (although you get a lot fewer barriers for some ops, esp on the read side).

My pet theory says that what really helps lock-free programming on x86 is not a relatively strong ordering of normal loads and stores, but the fact that all x86 synchronization instructions have both global order and strongest possible implied barriers.