3 ms·

I've wanted to use TSX for years... it's great as a way to get atomicity for non-primitive types in a lock-free way. Could be super useful in trading. The issu

I've wanted to use TSX for years... it's great as a way to get atomicity for non-primitive types in a lock-free way. Could be super useful in trading. The issue is it's been YEARS now that intel claims it's ready then turns it off in chips shortly thereafter. It's basically vaporware at this point.

Syonyk 5y ago
I spent a week or so a couple years back messing around with TSX as well to see if I could improve some performance of ringbuffers without having to do some more complex locking. It would have required a lot of rework, and someone else on the project pointed out that no TSX implementation seemed to survive extended contact with reality without being disabled. So I just wrote the more complex reader/writer lock system and went on my way. Turns out to have been the right answer... At this point, TSX is like a new Google product launch - "This, too, shall pass." I don't know why anyone would bother spending much time with it after all these generations of "TSX! Wait, no... uh..."
ploxiln 5y ago
I've disliked the idea of TSX since the beginning. Having studied some circuit design, computer architecture, and operating systems in college, though I work in user-space software now I do like to understand how all the layers beneath me work. TSX has always given me the heebie-jeebies. Sure it might give great performance uplift if you have a team of skilled scientists and engineers and servers dedicated to a single application. But for general computing, it's really crazy. Good for academic papers, good for marketing to the director level, bad for general engineering work. It turns out that it doesn't really work. Surprise! not really
- alfalfasprout 5y ago
  I'm not sure TSX was really intended to be used everywhere though. Admittedly the glibc team tried to use it in pthreads and it was a disaster (a lot of code broke and of course it kept getting disabled in CPUs). Their issue IMO was not really scoping down TSX... the project was far too ambitious.
  - ploxiln 5y ago
    Intel employees added it to glibc. I think Intel wanted to show everyone "don't be scared, silly, you're already using it!" https://lwn.net/Articles/534761/ https://lwn.net/Articles/534761/ http://halobates.de/adding-lock-elision-to-linux.pdf http://halobates.de/adding-lock-elision-to-linux.pdf
- lallysingh 5y ago
  Why? The implementation sounded simple: bus snoop on addresses used by the load unit, invalidate if anyone writes to those lines.
  - zozbot234 5y ago
    Like you say it's not addresses, it's implementation-dependant "lines" that may or may not be coincident with cachelines. False invalidations are absolutely a concern. (They're a concern already for CAS loops, which you need e.g. to do arbitrary read-modify-write on atomic-sized data. Hardware transactions only magnify these concerns.)
  - ploxiln 5y ago
    But also, maintain a bunch of memory and cpu state invisibly, and apply a bunch atomically or roll it back, and do this for multiple threads simultaneously. And then try debugging some seemingly unrelated issue at the memory/instruction level, and drop the assumption that everything below your level of abstraction works perfectly as you expect. And yes, this is very similar to mis-predicted branches and the speculative execution vulnerabilities. I have honestly tried to understand those at the instruction level, and felt like I did at one point, and then a few months later felt like I forgot some key details and couldn't put it together again... like I get the idea, but can't quite put together the assembly to demo the problem on my own, it's a bit of a mindfuck ...
alfalfasprout 5y ago
I agree, the implementation isn't great. The problem IMO is that it tried to do way too much and be way too general which leads to a bunch of tricky edge cases they need to handle (and significantly complicates uses of caches). That said, hardware support for atomic use of larger memory regions than is currently supported is something that is worthy as a problem to solve.
zozbot234 5y ago
Transactional memory can be implemented in software. It's not strictly dependent on hardware primitives like TSX.

Syonyk 5y ago

I spent a week or so a couple years back messing around with TSX as well to see if I could improve some performance of ringbuffers without having to do some more complex locking. It would have required a lot of rework, and someone else on the project pointed out that no TSX implementation seemed to survive extended contact with reality without being disabled. So I just wrote the more complex reader/writer lock system and went on my way. Turns out to have been the right answer... At this point, TSX is like a new Google product launch - "This, too, shall pass." I don't know why anyone would bother spending much time with it after all these generations of "TSX! Wait, no... uh..."

ploxiln 5y ago

I've disliked the idea of TSX since the beginning. Having studied some circuit design, computer architecture, and operating systems in college, though I work in user-space software now I do like to understand how all the layers beneath me work. TSX has always given me the heebie-jeebies. Sure it might give great performance uplift if you have a team of skilled scientists and engineers and servers dedicated to a single application. But for general computing, it's really crazy. Good for academic papers, good for marketing to the director level, bad for general engineering work. It turns out that it doesn't really work. Surprise! not really

alfalfasprout 5y ago
I'm not sure TSX was really intended to be used everywhere though. Admittedly the glibc team tried to use it in pthreads and it was a disaster (a lot of code broke and of course it kept getting disabled in CPUs). Their issue IMO was not really scoping down TSX... the project was far too ambitious.
- ploxiln 5y ago
  Intel employees added it to glibc. I think Intel wanted to show everyone "don't be scared, silly, you're already using it!" https://lwn.net/Articles/534761/ https://lwn.net/Articles/534761/ http://halobates.de/adding-lock-elision-to-linux.pdf http://halobates.de/adding-lock-elision-to-linux.pdf
lallysingh 5y ago
Why? The implementation sounded simple: bus snoop on addresses used by the load unit, invalidate if anyone writes to those lines.
- zozbot234 5y ago
  Like you say it's not addresses, it's implementation-dependant "lines" that may or may not be coincident with cachelines. False invalidations are absolutely a concern. (They're a concern already for CAS loops, which you need e.g. to do arbitrary read-modify-write on atomic-sized data. Hardware transactions only magnify these concerns.)
- ploxiln 5y ago
  But also, maintain a bunch of memory and cpu state invisibly, and apply a bunch atomically or roll it back, and do this for multiple threads simultaneously. And then try debugging some seemingly unrelated issue at the memory/instruction level, and drop the assumption that everything below your level of abstraction works perfectly as you expect. And yes, this is very similar to mis-predicted branches and the speculative execution vulnerabilities. I have honestly tried to understand those at the instruction level, and felt like I did at one point, and then a few months later felt like I forgot some key details and couldn't put it together again... like I get the idea, but can't quite put together the assembly to demo the problem on my own, it's a bit of a mindfuck ...

alfalfasprout 5y ago

I agree, the implementation isn't great. The problem IMO is that it tried to do way too much and be way too general which leads to a bunch of tricky edge cases they need to handle (and significantly complicates uses of caches). That said, hardware support for atomic use of larger memory regions than is currently supported is something that is worthy as a problem to solve.

zozbot234 5y ago

Transactional memory can be implemented in software. It's not strictly dependent on hardware primitives like TSX.