This all works with lock elision with TSX and similar HTM technologies. - interaction with non-transactional code including access to shared data from outs

This all works with lock elision with TSX and similar HTM technologies. - interaction with non-transactional code including access to shared data from outside of transactions The non transactional code just uses the lock, or it uses other suitable semantics when non locking code interacts with locking code (e.g. rules about read only vs writable with technologies like RCU). Any violations lead to aborts due to the cache coherency, and degrade to what would happen without transactions. - exception handling, and propagating exception info Just aborts the transaction, and then it works normally. - how would interaction happen with code that cannot fit this (transactional) model ? See above. - how to ensure that system makes progress in presence of conflicts (livelock) HTM is generally (with a few exceptions) best effort, so always needs to have a valid non transactional fall back path. Usually the fall back path However in practice this all rarely happens because real systems have enough noise, it's more a theoretical problem. - debugging aborted transactions You profile them. TSX has extensive facilities for that. I wrote about it here https://software.intel.com/en-us/blogs/2013/05/03/intelr-transactional-synchronization-extensions-intelr-tsx-profiling-with-linux-0 https://software.intel.com/en-us/blogs/2013/05/03/intelr-tra... There's also Processor Trace in newer Intel CPUs which makes it quite easy to see what's going inside transactions. Some of the issues you're describing happen with a full software transactional memory model, not a lock elision model, where you don't want to rely on locks. But even those can be mostly solved with straight forward techniques, by falling back to global locks. However most usage of HTM is not a full transactional model, but just lock elision, which doesn't really have any of these problems you're listing.