3 ms·
> You can verify that your implementation is capable of performing lock-free atomic operations on double-machine-word primitives with assert(data_ptr.is_lock_fr
by nimrody 9y ago
> You can verify that your implementation is capable of performing lock-free atomic operations on double-machine-word primitives with assert(data_ptr.is_lock_free()).
This may be true when compiling for a 32bit process and running on a 64 bit machine, but is not true for the more common 64 bit program on x86_64 (since pointers are 64 bit.)
- twoodfin 9y agodata_ptr is an atomic-wrapped struct of an int and a pointer. If it’s lock-free you must be running somewhere with at least DCAS. (Maybe you’re saying the statement is true but that assertion will be false on x86_64? But CMPXCHG16B has been around for a while.)
- nimrody 9y agoIt is false for x86_64 when compiling with gcc 7.2 or clang 4.0. Not sure you can make atomic.h use CMPXCHNG16B.
- twoodfin 9y agoThat’s very surprising. Did you specify -march? If the compilers have to support ALL x64 then they can’t use it, since it’s a 2004-ish addition.
- gpderetta 9y agostd::atomic<something-128bit-sized> do, or at least did last time I checked, use cmpxcg16b on gcc. There were talks about changing that because of surprising behavior: as there is no 128 atomic load, even loads need to use the cas, making them significantly slower than 'normal' atomic loads; also const std::atomic<128bit> is unusable in read only pages which is an expected use case for atomics. I do not know whether that has actually been 'fixed' though.