Andrey (andrey.semashev.delete@this.gmail.com) on April 8, 2021 8:18 am wrote:
> anon2 (anon.delete@this.anon.com) on April 8, 2021 5:18 am wrote:
> > Andrey (andrey.semashev.delete@this.gmail.com) on April 8, 2021 3:50 am wrote:
> > > Adrian (a.delete@this.acm.org) on April 8, 2021 3:09 am wrote:
> > > > 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:
> > > > > >
> > > > > > 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.
> > > >
> > > > They do only when they are the side effect of a hardware interrupt.
> > > >
> > > > If hardware interrupts are excluded, as in the previous sentence, then indeed
> > > > thread preemption or signal delivery do not happen out of the blue, but just as
> > > > a side-effect of an action done in the program, e.g. invoking a system call.
> > > >
> > > > So I assume that the previous poster meant that if you exclude the hardware interrupts by
> > > > masking them and you also avoid anything that might cause thread preemption or signal delivery,
> > > > i.e. invoking system calls, then you can avoid the aborts caused by such events.
> > >
> > > In that case interrupt masking would have to be part of the LL/SC
> >
> > Are you joking? We've *just* been over this. No, it wouldn't. LL/SC needs nothing of the sort.
>
> What we've been through is you telling me I'm wrong and then basically confirming what I said. Namely
> that interrupt masking is not part of LL/SC architecture and that it can be cheated around by the
> implementation. Yes, that would be a valid implementation and yes, that optimization would help LL/SC
> to work more reliably. No, that is not enough to say that LL/SC has a forward progress guarantee.

What are you even blathering about? You still don't get it.

> If we can't come to an agreement here - fine, then there's nothing more to discuss.

Good stop posting until you know the very basics of how interrupts and task scheduling works.

>
> > > or HTM architecture.
> >
> > Also wrong. HTM can cope with it by failing and returning to the fallback path,
> > as a counter-example. PowerPC can suspend transactions too which I believe is
> > another way to cope with this but I'm not clear on the details of that.
>
> Sure, same as LL/SC can cope by retrying.

Wrong. You just refuse to get it don't you? LL/SC is not a fallback path. Do you still not understand the difference??

> The goal, though, is to minimize
> the amount of aborts, hence the optimizations like interrupts masking.

You had no idea about implicitly disabling interrupts until I brought it up before.

>
> You can make optimizations like that (i.e. by not requiring the particular behavior
> in the architecture), but then you get TSX, which is a valid implementation
> of a loose design architecture that doesn't work well in practice.

You don't understand the difference between a retry and and a fallback, and yet incredibly you make proclamations like this as though you are a great expert in HTM.

>
> > > Which it isn't, at least not for x86 or ARM, as far as I know.
> > >
> > > There is also the possibility of a page fault, which cannot be anticipated by the program.
> >
> > Your point being?
>
> Please re-read what I was replying to.
>

I don't know what point you are making about it though. Page faults make things even worse for transactions in terms of being able to guarantee progress. LL/SC sequences of such guarantee typically don't make any allowance for other memory operations inside the critical section so page faults are a non-issue there.