3 ms·
As I understand it, HLE is the wrong solution for high-contention critical sections. The locks themselves are added to the transaction's read set [1], which me
by colanderman 13y ago
As I understand it, HLE is the wrong solution for high-contention critical sections. The locks themselves are added to the transaction's read set [1], which means that if any of the concurrently executing transactions of this critical section are re-executed non-speculatively, then all these transactions are re-executed non-speculatively, and importantly: any future transactions which overlap these will be executed non-speculatively, potentially indefinitely.
You really want full RTM for such high-contention situations.
I would love to be wrong about this, but I haven't a Haswell to test on.
Also, classy shout-out (beg-out?) to Intel's free samples division at the end there.
[1] http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/composerxe/compiler/cpp-win/GUID-A462FBC8-37F2-490F-A68B-2FFA8010DEBC.htm http://software.intel.com/sites/products/documentation/docli...
- sp332 13y agoFTA: one of the updates might be lost, something we see from time to time. You're right, but it doesn't sound like these are high-contention operations since they currently run without any locks and rarely have problems.
- colanderman 13y agoSorry, I meant high contention on the lock – if they plan on using a coarse-grained lock, I presume it will see high contention (assuming they have many statistics). Obviously if they plan on using one lock per statistic, this isn't a problem, but then they should just be using atomic updates instead.