Andrey (andrey.semashev.delete@this.gmail.com) on April 8, 2021 2:41 am wrote:
> 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.

You're just wrong. If interrupts aren't allowed, then thread preemption and signal delivery are non-issues, because they are driven by interrupts.

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

You completely miss the point. Again. You still seem to think we're talking about forward progress requiring interrupts to be arhcitecturally suspended. We're not, it's just something you've concocted in your own mind.

The architecture absolutely can guarantee forward progress, without requiring interrupts to be disabled over LL/SC, and the implementation can choose to hold off interrupts if it chooses as a way to implement that if that's what they decide, and it doesn't even need to be over every LL/SC, they could drop to a slower suspend interrupts mode after detecting some failures.

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

We're talking about progress of one thread here, was it honestly so difficult to comprehend that from the context?

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

Again: zero sane architectures require a fallback path for LL/SC. You're just wrong.

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

You're going to cease arguing about it, you mean?

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

Given your ideas about signals or task switching somehow unexpectedly arriving in the middle of a transaction without a hardware interrupt coming in, I'm going to go ahead and assume this opinion is not based on any kind of real world learning or experience.