anon2 (anon.delete@this.anon.com) on April 8, 2021 12:52 am wrote:
> 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:
> > > >
> > > > 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!

As far as the running program is concerned, they do.

> > 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.

Again, that would be an implementation detail of a given microarchitecture, not a guarantee.

> > > > 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.

Forward progress guarantee means that at least one thread is guaranteed to make progress. When I say you don't have this guarantee, it means there is a case, however theoretical, where none of the threads make progress.

> > > 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?

All LL/SC architectures require a retry, which is a sign that forward progress is not guaranteed.

> > 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.

Well, I'm not going to argue who was the first to suggest what. I'll just say that I think I agree with Linus on some points and not the other. In particular, I don't agree with his views on transaction constraints, and that these constraints would make that HTM design a success.