3 ms·

This sounds like a weird variant of double checked locking where the check-and-take is part of the transaction. That sounds like it breaks composability. Can y

• jcranmer 7y ago
  I'm not an expert on the x86 implementation, but my understanding of its implementation of hardware lock elision in this: A lock in x86 is usually implemented as an atomic variable, with a read-modify-write to acquire it and another to release it, with appropriate memory barriers to squelch incorrect memory reordering. Hardware lock elision is described with a prefix to these read-modify-write instructions to indicate that it's a lock acquire instruction or a lock release instruction. What the hardware will do is first ignore the lock and execute the code as a transaction. If the transaction fails (which usually means another processor is writing to the same memory location), it restarts at the lock-acquire instruction and executes the regular locking code. As you might imagine, this has all sorts of potentially crazy interactions with the regular memory model. The article that's linked here is a paper that built a full memory model of both the normal hardware/C++11 memory model and the transactional memory semantics, and then they use it to see if the hardware lock elision is actually correct. They found that the ARM model is broken, but the POWER and x86 hardware lock elision is correct.
  • foobiekr 7y ago
    Thanks, that makes more sense.