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:
> > > 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.
>
> 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 or HTM architecture. 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.

Other hardware exceptions are probably not as relevant, although I would imagine invalid instruction exceptions could be relevant if a certain instruction is supposed to be emulated by the kernel.

> However, masking the interrupts is obviously not a solution for user
> programs, where the transactional memory is supposed to be useful.

Interrupt masking as part of HTM design could be useful in some limited capacity. You can't straight disable interrupts on transaction begin and enable at its commit or abort as that would allow for disabling interrupts practically indefinitely. However, reducing the rate of interrupts or guaranteeing a certain minimal amount of time of interrupts being masked, could be useful. Note that this doesn't mean longer transactions must always fail.