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.

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