atomic.load() 是否比正常调用更快

Question

Recently I have been using atomic numbers alot in c++ as i use threading too much and thread safe is important to me

Well, I had a problem with printf() function here is an example

atomic_uint64_t count = {0}

printf("%lu",count);

// It gives error couple of errors like  atomic(cost atomic&) = delete; and use of deleted function atomic so i had to write it like this to make it work

printf("%lu",count.load());

// Or

printf("%lu",(uint64_t)count);

Well anyways i don't which is better for performance i really care about the speed

So i started to thinking about which is better to retrieve the value and use it in if conditions or anywhere else

Like

if(count.load() < 8 ){

// Do smth
}

or

if(count < 8){
// Do smth
}

Which is better for speed and performance and thanks.

Answer 1

They're exactly identical in their meaning (unless you pass a non-default memory order like count.load(std::memory_order_acquire) ).

I'd expect there to be no difference in the generated assembly for all compilers across all ISAs, with optimization enabled of course. There isn't for GCC/clang/MSVC/ICC in code I've looked at on https://godbolt.org/ . This is true regardless of surrounding code its inlining into.

If there is ever a difference, and one is slower or takes more code-size, report that as a missed-optimization compiler bug in whatever compiler you're using. (Unless you had optimization disabled, then an extra level of calls to wrapper functions is possible.)

---

As for the error, that's because you're evaluating it in a context that doesn't already imply a type: as an operand for a variadic function ( printf ).

If there's enough context to imply that you want the underlying T value from an atomic<T> (which is what atomic_uint64_t is), then the operator T() overload is called, which is documented as being equivalent to .load() . Same deal for assignment and .store() .

There aren't any other functions that let you access only the low 32 bits of an atomic 64-bit integer (unfortunately); even on a 32-bit machine, current compilers will actually go to the trouble of doing a 64-bit atomic load (which is efficient on some 32-bit machines, not on others), then discarding the high 32 if you cast the value to a narrower type. (This is a missed-optimization, but compilers truly don't optimize atomics for the moment.)

So there's no ambiguity being resolved by .load , or any way a cast can pick a different load.

---

One reason for the existence of .load() and .store() is that they take a std::memory_order parameter, which is defaulted to seq_cst but can be weaker if you just need atomicity but only acq/rel synchronization between threads. Or none at all with relaxed , just atomicity.

Another reason is to let you write foo.load() to remind readers of you code that this is an atomic variable, not just a plain primitive type. For that style reason I'd prefer count.load() . Presumably if you changed its type away from uint64_t , you'd want to change how you printed it, not still cast it to uint64_t . Using .load() will let the compiler warn you about the format-string mismatch if you change its type.