By: Ben LaHaise (bcrl.delete@this.kvack.org), April 6, 2021 2:43 pm
Room: Moderated Discussions
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?
Yes. Untested or lightly tested code is virtually impossible to ensure correctness on. The more corner cases there are that are difficult to exercise, the higher the likelihood of bugs cropping up in production is.
> 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.
The interaction of interrupts with transactions is significant. In an ideal world, hardware would restart the transaction until it succeeds, and would ensure that there is forward progress. Anything else is throwing a festering pile of crap back at programmers. Time and time again the difficulty of getting locking right in high performance code has been shown to be extremely difficult (just witness the last 20 years of Linux kernel development). Adding an footnote saying that "hey, your code does something really weird in this corner case that only happens under this magical mix of preconditions hits in the hardware" is a complete nightmare for any competent systems programmer, and even worse for the less skilled coders. This is not a path to sanity for a feature that's supposed to improve performance as other posts in this thread have documented.
-ben
> 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?
Yes. Untested or lightly tested code is virtually impossible to ensure correctness on. The more corner cases there are that are difficult to exercise, the higher the likelihood of bugs cropping up in production is.
> 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.
The interaction of interrupts with transactions is significant. In an ideal world, hardware would restart the transaction until it succeeds, and would ensure that there is forward progress. Anything else is throwing a festering pile of crap back at programmers. Time and time again the difficulty of getting locking right in high performance code has been shown to be extremely difficult (just witness the last 20 years of Linux kernel development). Adding an footnote saying that "hey, your code does something really weird in this corner case that only happens under this magical mix of preconditions hits in the hardware" is a complete nightmare for any competent systems programmer, and even worse for the less skilled coders. This is not a path to sanity for a feature that's supposed to improve performance as other posts in this thread have documented.
-ben