TX lock elision

Posted Jan 25, 2026 12:53 UTC (Sun) by ballombe (subscriber, #9523)
Parent article: GNU C Library 2.43 released

> * The support for TX lock elision of pthread mutexes has been removed on all
architectures (powerpc, s390x, x86_64).

Any detail ?

to post comments

TX lock elision

Posted Jan 25, 2026 13:22 UTC (Sun) by csamuel (✭ supporter ✭, #2624) [Link] (7 responses)

The thread where it was decided to deprecate it (which started off as just S390x wanting to remove it as hardware support was deprecated in z16 and reduced in z17) is here: https://sourceware.org/pipermail/libc-alpha/2025-July/168... and the deprecation patch is here: https://sourceware.org/pipermail/libc-alpha/2025-July/168...

There was a very short thread on the removal itself, which includes this comment about ARM64 also obsoleting transactional memory support. https://sourceware.org/pipermail/libc-alpha/2025-November...

TX lock elision

Posted Jan 25, 2026 19:43 UTC (Sun) by ballombe (subscriber, #9523) [Link] (6 responses)

So it is yet another hardware feature that does not pan out.

TX lock elision

Posted Jan 25, 2026 20:23 UTC (Sun) by csamuel (✭ supporter ✭, #2624) [Link]

Sadly yes. Back in 2012 when we were getting our BlueGene/Q there was a lot of excitement about it having HTM but it never came to anything. There was this paper from IBM itself (PDF) https://dl.acm.org/doi/pdf/10.1145/2370816.2370836 which says:

> While it is widely expected that such overheads be significantly reduced in an HTM, one of the surprising findings of this performance study is that, the BG/Q HTM overhead, while much smaller than that of STM’s, is still non-trivial. The causes of HTM overheads are also very different from those of STM’s. For instance, BG/Q TM maintains speculative states in the L2 cache. This allows for transactions with a large memory footprint, the price to pay, however, is the overhead, where the L1 cache is either bypassed during a transaction or flushed upon entry to a transaction. The loss of cache locality is the dominant cause of BG/Q TM overhead

TX lock elision

Posted Jan 25, 2026 21:27 UTC (Sun) by josh (subscriber, #17465) [Link] (4 responses)

That's pretty much the history of transactional memory, both software and hardware.

https://imgur.com/a/cXCtzsr

TX lock elision

Posted Jan 26, 2026 6:22 UTC (Mon) by pthariensflame (subscriber, #169079) [Link] (1 responses)

For whatever it's worth, (software) transactional memory has found genuine sustained use in one specific ecosystem: Haskell, in which the monad-based effect control makes it a lot less error-prone to use.

TX lock elision

Posted Jan 27, 2026 1:49 UTC (Tue) by josh (subscriber, #17465) [Link]

I'm familiar (I used to program Haskell), but I also think it fits Haskell because it optimizes for compositional simplicity at the expense of performance.

TX lock elision

Posted Feb 8, 2026 17:33 UTC (Sun) by joib (subscriber, #8541) [Link] (1 responses)

Amusingly, it seems a patch queued up for the 6.20 (or 7.0 if Linus decides to bump the major version number?) kernel enables it on x86, with a mention in the commit msg stating that SUSE has been having it enabled for a long time.

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.g...

7.0

Posted Feb 8, 2026 20:42 UTC (Sun) by corbet (editor, #1) [Link]

At the Maintainers Summit, Linus told us that the next release would be 7.0. No need to wonder about that — unless he changes his mind, of course.