sr (nobody.delete@this.nowhere.com) on April 6, 2021 9:22 am wrote:
> dmcq (dmcq.delete@this.fano.co.uk) on April 6, 2021 7:05 am wrote:
> > If all the control is done via HTM rather than locks then deadly embraces can be avoided
> > if the oldest transaction can always cause a newer one to restart. There's a lot more problems
> > besides that though which I think means it should be restricted to small things where one
> > can assume a successful execution can defer an interrupt till it finishes.
>
> I a fallback path big problem?
>
> TM execution guarantees by hardware that memory transaction is atomic. Fallback path is to provide
> non-atomic path to software if hardware cannot guarantee atomic operation. To guarantee forward
> progress with only atomic memory path need modifications to hardware and programming models,
> or restrict operation so that it can be always successfully completed atomically.
>
> I don't think that interrupts are problem, transaction
> could be aborted whether thread is running or suspended.

Interrupts are a problem if they cause anything more than a very small proportion of transactions to fail. And the proportion goes up with the size of the transaction. The processor could have been doing good work that is interruptible if it had been using locks and that is all thrown away. So it is best if interrupts are done by another processor or delayed a bit if possible.

And I really don't see how one can expect very much gain unless hardware transactions can be overlapped so there can be some forms of conflict without aborting. Otherwise one is balancing the overheads of locks against the overheads of aborts.