Hacker News Reader

Comment by dist-epoch | Hacker News Reader

I think Intel x86 had some hardware support for STM at some point. Not sure what's the status of that.

Disabled on most CPUs, plagued by security issues. I haven't used it but I assume debugging would be extremely painful, since any debug event would abort the transaction.

That's not software transactional memory, it's hardware transactional memory, and their design was not a good one.

Well, HTM was not useful per se, except accelerating an STM implementation.

It isn't very useful for that, but you can use it to implement other higher-level concurrency primitives like multi-word compare and swap efficiently.

True. At some point in the now distant past, AMD had a proposal for a very restricted form of HTM that allowed CAS up to 7 memory locations as they had some very specific linked list algorithms that they wanted optimize and the 7 location restrictions worked well with the number of ways of their memory.

Nothing came out of it unfortunately.

I'd like to see what kind of hardware acceleration would help STMs without imposing severe limitations on their generality.

To me, the appealing things about STMs are the possibility of separating concerns of worst-case execution time and error handling, which are normally pervasive concerns that defeat modularity, from the majority of the system's code. I know this is not the mainstream view, which is mostly about manycore performance.

Not an expert, but my understanding is that HTM basically implements the fast path: you still need a fully fledged STM implementation as a fallback in case of interference, or even in the uncontended case if the working set doesn't fit in L1 (because of way collision for example) and the HTM always fails.

I'm no expert either, but maybe some other hardware feature would be more helpful to STMs than hardware TM is.

Reply on news.ycombinator.com