4 ms·

Shame. When TSX was announced in 2012, I started looking forward to a day, years down the line, when it would be ubiquitous enough that I could write code that

by comex 7y ago

Shame. When TSX was announced in 2012, I started looking forward to a day, years down the line, when it would be ubiquitous enough that I could write code that depended on it. (At least on Macs, which don't run AMD processors.) The first processors supporting it shipped in 2013... but then in 2014 Intel abruptly disabled it in all then-shipping processors via microcode update, due to an erratum. Eventually they started shipping processors without the bug, and 4-5 years passed, a decent chunk of the time needed for ubiquity. But now the clock's reset to zero once again. Though, apparently Intel always disabled TSX on i3 processors for product segmentation, so maybe universal support was never in the cards... I wish more CPUs would support at least a limited version of this. Basically, I want the equivalent of atomic<shared_ptr<T>>, but lock-free. That requires reading a pointer value from memory and then incrementing a reference count stored at that pointer, as a single atomic operation. I'm pretty sure that's doable with TSX, although I haven't actually tried it.

mmastrac 7y ago
Ditto - and it seems like every time TSX was "re-released", it ended up being disabled later on for some random microcode issue. Transactional memory is hard!
roblabla 7y ago
FWIW, my understanding is that XBEGIN/XEND/XABORT are still available on the affected CPUs. Only XACQUIRE/XRELEASE are disabled. So the clock isn't really reset. I, too, wish TSX was more ubiquitous. I'm working on a kernel, and was hoping to use TSX to greatly simplify the logic of safely reading user memory from kernelspace - catching various exception cases without going through the real exception handler. Turns out, none of the machines I have at my disposal have TSX - not my Desktop PC nor my server machine. So, RIP that plan, I guess. What you want is absolutely doable with TSX. The overhead might be significant though. I wouldn't be surprised if locking a mutex was faster.
- jdsully 7y ago
  You can’t simplify the logic because TSX transactions may abort for any reason and make no promises of forward progress. You must implement a fallback codepath. If you meant having an optimized codepath then that is doable. But given your writing a kernel there may be microarchitectural hazards that trigger excessive aborts.
  - amluto 7y ago
    Forget microarchitectural issues. If you have user memory paged out (or not present for accounting reasons, etc), you can try to access it in a transaction until the cows come home and it will never work — to make progress, you need to update the page tables either via a page fault or manually.
    - roblabla 7y ago
      Not an issue for me, my kernel has no swap or other such thing - by design. Of course I realize not everyone is in my shoes - such an approach would absolutely fail on Linux!
  - roblabla 7y ago
    Yeah, at first I wanted to use TSX exclusively, but I came to the same conclusion you did while digging into it more deeply. I still think having a fast path using TSX could be useful, but since I never had a CPU with it, I never had a chance to benchmark it.
    - saagarjha 7y ago
      > I still think having a fast path using TSX could be useful That’s what TSX is intended to be: a path that runs faster when possible.
    - jdsully 7y ago
      In some cases it can have a huge speedup. But it's rather tricky to get right. So far for almost all of my use cases the transaction sizes have been too large, and it almost always aborted. The RPCS3 PS 3 emulator saw a 40% perf boost so some amazing gains are possible. https://www.phoronix.com/scan.php?page=news_item&px=RPCS3-Intel-TSX-Support https://www.phoronix.com/scan.php?page=news_item&px=RPCS3-In...
ot 7y ago
> I want the equivalent of atomic<shared_ptr<T>>, but lock-free. You can do that without transactions with a lock cmpxchg16b instruction, or with a more complicated algorithm like this: https://github.com/facebook/folly/blob/3de8f357eecaff89e3847fdb4f090767c2d42e81/folly/concurrency/AtomicSharedPtr.h https://github.com/facebook/folly/blob/3de8f357eecaff89e3847...
- MaxBarraclough 7y ago
  Is there a reason a standard-compliant implementation of atomic<shared_ptr<T>> couldn't use that approach? Or is it just a matter of someone doing it?
mzs 7y ago
Sadly TSX was just a bad idea from the get-go.

by comex 7y ago

mmastrac 7y ago

Ditto - and it seems like every time TSX was "re-released", it ended up being disabled later on for some random microcode issue. Transactional memory is hard!

roblabla 7y ago

FWIW, my understanding is that XBEGIN/XEND/XABORT are still available on the affected CPUs. Only XACQUIRE/XRELEASE are disabled. So the clock isn't really reset. I, too, wish TSX was more ubiquitous. I'm working on a kernel, and was hoping to use TSX to greatly simplify the logic of safely reading user memory from kernelspace - catching various exception cases without going through the real exception handler. Turns out, none of the machines I have at my disposal have TSX - not my Desktop PC nor my server machine. So, RIP that plan, I guess. What you want is absolutely doable with TSX. The overhead might be significant though. I wouldn't be surprised if locking a mutex was faster.

jdsully 7y ago
You can’t simplify the logic because TSX transactions may abort for any reason and make no promises of forward progress. You must implement a fallback codepath. If you meant having an optimized codepath then that is doable. But given your writing a kernel there may be microarchitectural hazards that trigger excessive aborts.
- amluto 7y ago
  Forget microarchitectural issues. If you have user memory paged out (or not present for accounting reasons, etc), you can try to access it in a transaction until the cows come home and it will never work — to make progress, you need to update the page tables either via a page fault or manually.
  - roblabla 7y ago
    Not an issue for me, my kernel has no swap or other such thing - by design. Of course I realize not everyone is in my shoes - such an approach would absolutely fail on Linux!
- roblabla 7y ago
  Yeah, at first I wanted to use TSX exclusively, but I came to the same conclusion you did while digging into it more deeply. I still think having a fast path using TSX could be useful, but since I never had a CPU with it, I never had a chance to benchmark it.
  - saagarjha 7y ago
    > I still think having a fast path using TSX could be useful That’s what TSX is intended to be: a path that runs faster when possible.
  - jdsully 7y ago
    In some cases it can have a huge speedup. But it's rather tricky to get right. So far for almost all of my use cases the transaction sizes have been too large, and it almost always aborted. The RPCS3 PS 3 emulator saw a 40% perf boost so some amazing gains are possible. https://www.phoronix.com/scan.php?page=news_item&px=RPCS3-Intel-TSX-Support https://www.phoronix.com/scan.php?page=news_item&px=RPCS3-In...

ot 7y ago

> I want the equivalent of atomic<shared_ptr<T>>, but lock-free. You can do that without transactions with a lock cmpxchg16b instruction, or with a more complicated algorithm like this: https://github.com/facebook/folly/blob/3de8f357eecaff89e3847fdb4f090767c2d42e81/folly/concurrency/AtomicSharedPtr.h https://github.com/facebook/folly/blob/3de8f357eecaff89e3847...

MaxBarraclough 7y ago
Is there a reason a standard-compliant implementation of atomic<shared_ptr<T>> couldn't use that approach? Or is it just a matter of someone doing it?

mzs 7y ago

Sadly TSX was just a bad idea from the get-go.