sr (nobody.delete@this.nowhere.com) on April 7, 2021 9:42 am wrote:
> Ben LaHaise (bcrl.delete@this.kvack.org) on April 6, 2021 3:43 pm wrote:
> > 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.
>
> I do agree. But as fallback code is a fallback situation it's not critical for performance. So to
> get locking done right on non-performance critical code should still be doable pretty easily. Locking
> problems arise when you start to optimize your locking code to better exploit concurrency.
>
>
>
> [quote]
> > 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
> >
>
> [/quote]
>
> But there it is. Locking is nearly impossible to get right.

No it's not.

>
> Transactional memory isn't all about performance. It's locking done by hardware. Transactional
> memory is damn useful even when done with software when it offers only fraction of performance
> of properly tuned locking scheme - you still get memory ordering done right and won't
> have to melt your brains debugging complex locking algorithms.
>
> Performance boost is only a side bonus. And it's not a little one either.
>
> And if transactional memory is only wanted to use to performance boost it's possible to just do
> lock elision - replace traditional locks with speculative ones. Same code should work for transitional
> and non-atomical path. Hardware could be easily done so that after speculative locking failed it
> just takes locked path. But wasting great hardware to doing only that would be stupid....