By: sr (nobody.delete@this.nowhere.com), April 7, 2021 9:42 am
Room: Moderated Discussions
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.
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....
> 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.
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....
