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.

▲

gpderetta 10 hours ago | parent [-]

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.

▲

kragen 9 hours ago | parent [-]

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.

▲

gpderetta 9 hours ago | parent [-]

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.

	▲	kragen 9 hours ago \| parent [-]
		I'm no expert either, but maybe some other hardware feature would be more helpful to STMs than hardware TM is.