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. If we can't come to an agreement here - fine, then there's nothing more to discuss.

> > 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. The goal, though, is to minimize the amount of aborts, hence the optimizations like interrupts masking.

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.

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