Andrey (andrey.semashev.delete@this.gmail.com) on April 8, 2021 12:29 am wrote:
> anon2 (anon.delete@this.anon.com) on April 7, 2021 8:12 pm wrote:
> > Andrey (andrey.semashev.delete@this.gmail.com) on April 7, 2021 5:33 pm wrote:
> > > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on April 7, 2021 5:12 pm wrote:
> > > > Andrey (andrey.semashev.delete@this.gmail.com) on April 7, 2021 2:32 pm wrote:
> > > > >
> > > > > LL/SC is a very restricted version of HTM. You do have to retry in software if SC fails, although you
> > > > > normally don't implement a fallback path hoping that it will eventually succeed. Note that forward progress
> > > > > is not guaranteed with LL/SC. That is unlike regular atomics, which makes them superior.
> > > >
> > > > All quality implementations of LL/SC do guarantee forward progress.
> > > >
> > > > That guarantee is conditional on the LL/SC region being sufficiently small (the
> > > > same way I'd suggest a transaction size be limited), but that obviously not an issue
> > > > for the simple unconditional ALU operation cases that the atomics support.
> > > >
> > > > At least alpha, arm and RISC-V have that guarantee architecturally. I'm
> > > > pretty sure powerpc does too, but don't have the papers in front of me.
> > >
> > > How can the forward progress be guaranteed if the thread
> > > can be interrupted in the middle of LL/SC body, which
> > > resets the LL tag? As long as that is a possibility, you cannot have a guarantee of forward progress.
> >
> > Uh, why would you have to allow interrupts there??
>
> I used the term "interrupted" broadly here. It's not necessarily hardware
> interrupts, but e.g. thread preemption and signal delivery.

Ah, so you don't know what you're talking about then. That explains a lot.

Thread preemption and signal delivery don't just "happen" out of the blue while a CPU is executing instructions!

>
> And regarding hardware interrupts, at least in case of ARM, I don't think interrupts are architecturally suspended
> by a LL. I suppose, a particular implementation might do some tricks to postpone interrupt handling past SC,
> but firstly, that would not something to rely on, and secondly, you can postpone for only so long.

Totally missed the point. Of course interrupts are not architecturally suspended. Nobody said they were. The point is if your architecture gives a recipe for LL/SC sequences that can be assumed to eventually succeed, then the *microarchitecture* can suspend them.

>
> > > Of course, the case when the LL/SC loop gets constantly interrupted and cannot progress is
> > > pathologic and largely theoretical, but still it breaks the strict forward progress guarantee.
> >
> > The forward progress that Linus is talking about (the actual important practical guarantee) is that a core
> > doesn't get stuck forever failing its SC because other agents in the machine keep taking its line away.
>
> And that can happen, too, although as long as those other agents
> progress, this doesn't impact the forward progress guarantee.

It obviously does not guarantee forward progress for that CPU.

>
> > > And conversely, HTM (TSX included) can be viewed as having the same kind of soft forward progress
> > > guarantee, as long as its body is small enough and doesn't unconditionally abort.
> > >
> >
> > Were you not reading the thread? This is the exact kind of thing Linus said might actually be useful.
> >
> > He nowhere said that such a thing can't possibly be done (and he even said it is in mainframes). It's
> > the problem of using x86 transactions that way (other than
> > bad performance) is because there is no architectural
> > specification telling us the conditions under which it is guaranteed to eventually succeed.
>
> I'm not sure what you're talking about here. I'm not saying HTM can't have a soft forward progress
> guarantee, like LL/SC. On the opposite, I'm saying that it does.

You are wrong. Many *actual* HTM implementations do not. Intel's does not, I think POWER does not. Contrary to this, no sane architecture requires a LL/SC fallback (for certain constrained sequences). What is difficult to understand about this?

> My point is that on both cases
> it's not a strict guarantee, which means you have to have a retry/fallback path.

No.

>
> In the particular case of TSX the spec describes cases when the transaction will abort. The
> problem is that it lists microarchitectural causes, which is basically a license for the CPU
> to abort at its whim. And my suggestion is to minimize or straight eliminate those causes.
>

It's not _your_ suggestion though, Linus has been talking about the usefulness of such constrained guaranteed transactions for the entire thread here. Nobody denies that, you're tilting at windmills or something because you're not understanding what people are saying, evidently.