After reading Anandtech on 'Haswell TSX' (tranactional memory barriers) I immediately wondered if CLR/JVM will be able to make use of these in C#/Java/Scala/F# for heavily parallel applications (C# Rx/TPL/TFD).
Old question, but I thought I'd add a new answer with at least one concrete pointer
Intel has done experimentation using their TSX system to elide locks in Java, published here. Typical results though are only 2-3% on standard benchmarks such as SpecJVM2008, though one benchmark does see 18% improvement. Synthetic benchmarks see much better results, but the results are... synthetic.
HLE (hardware lock elision) can be easily integrated into any existing codebase that uses locks. For example, there is already exists an implementation for pthreads. Also, note that JVM already performs lock elision optimization, I think they can switch to hardware lock elision when possible easily.
But things gets more complicated with transactions. You can't start a transaction and push 1Mb of updates, your transaction will be aborted. Because of that, hardware transactional memory is limited, it is not as composable and modular as software transactional memory. It is a very low-level thing. Also, note that not every function can be called safely from transactions. Such function must be free from side effects.
Because of that, I expect TSX will be available in CLR in form of compiler intrinsics that will be used by framework developers to create better concurrent collections and synchronization primitives. It won't be like Haskell's or Clojure's transactional memory.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With