By: sr (nobody.delete@this.nowhere.com), April 9, 2021 11:56 pm
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on April 7, 2021 10:35 am wrote:
> No.
>
> Transactional memory doesn't make locking easier. Not at all.
>
> Transactional memory makes locking much harder. It adds a lot of new cases, it
> adds all that fallback logic, and it adds a huge number of debugging problems.
Let's start from basics. I can't be only one that have been wondering why there isn't lock/unlock instruction for shared memory regions? It should be there so it could be always used instead of software locking, which is always hard to implement and debug.
It isn't there because it's a little hard to implement in hardware.
But it can be done.
For quick look at TSX it seems to exist to provide starting point for software development and provide quite good evolving path for hardware.
As fallback logic - it's just the evil that needs to be there with current hardware implementation. To provide forward progress they need to provide unlimited memory for transactions. To make it happen it needs both OS and hardware support to being able spill transactions to memory - and for hardware implementation that probably would be too costly now as most of benchmarked software won't make any use of transactions.
And about that big transactions are more probably of aborting - of course big transactions are chopped to smaller ones. In closed nesting parent transaction is safe from child transaction aborts if harware supports(TSX now support closed nesting but aborts always everything from beginning of first transaction at current harware implementation) and in open nesting parent transaction can commit without child transactions - that isn't supported in TSX yet.
But in the end if you got some functional transaction memory to operate with you could lock memory in fine-grained fashion where hardware does hard part - for most part deadlocks and other unwanted memory lock problems just go away because locking is done in hardware instead of software.
But using transactional memory just for lock elision where all hard work is done already for locking and just except higher performance because of opportunistic execution of traditional software locking is a bit disparaging attitude towards tranactional memory possibilities.
> No.
>
> Transactional memory doesn't make locking easier. Not at all.
>
> Transactional memory makes locking much harder. It adds a lot of new cases, it
> adds all that fallback logic, and it adds a huge number of debugging problems.
Let's start from basics. I can't be only one that have been wondering why there isn't lock/unlock instruction for shared memory regions? It should be there so it could be always used instead of software locking, which is always hard to implement and debug.
It isn't there because it's a little hard to implement in hardware.
But it can be done.
For quick look at TSX it seems to exist to provide starting point for software development and provide quite good evolving path for hardware.
As fallback logic - it's just the evil that needs to be there with current hardware implementation. To provide forward progress they need to provide unlimited memory for transactions. To make it happen it needs both OS and hardware support to being able spill transactions to memory - and for hardware implementation that probably would be too costly now as most of benchmarked software won't make any use of transactions.
And about that big transactions are more probably of aborting - of course big transactions are chopped to smaller ones. In closed nesting parent transaction is safe from child transaction aborts if harware supports(TSX now support closed nesting but aborts always everything from beginning of first transaction at current harware implementation) and in open nesting parent transaction can commit without child transactions - that isn't supported in TSX yet.
But in the end if you got some functional transaction memory to operate with you could lock memory in fine-grained fashion where hardware does hard part - for most part deadlocks and other unwanted memory lock problems just go away because locking is done in hardware instead of software.
But using transactional memory just for lock elision where all hard work is done already for locking and just except higher performance because of opportunistic execution of traditional software locking is a bit disparaging attitude towards tranactional memory possibilities.
