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


You are of course right, but when I have written "avoid anything that might cause thread preemption or signal delivery", I have also meant avoid anything that can cause exceptions.

"Invoking system calls" was just the most obvious example.

Page faults can be avoided by taking care to touch all the used pages before entering the transaction. Any other exceptions can also be avoided by careful programming.

In any case, regardless whether it could be possible or not to avoid the hardware interrupts, the exceptions and the system calls during transactions, I do not believe that a transactional memory can be useful, because I think that the additional hardware complexity outweighs the possible gains, even in the unlikely case when an implementation without bugs would be possible.