Hacker News Reader

> 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.)

View on HN

data_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.)

It is false for x86_64 when compiling with gcc 7.2 or clang 4.0. Not sure you can make atomic.h use CMPXCHNG16B.

That’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.

std::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.

Reply on news.ycombinator.com