12

I am trying to use std::atomic library.

  1. What's the difference between specialized and non-specialized atomic member functions?
  2. What's the difference (if there is any) between following functions?
  3. operator= stores a value into an atomic object (public member function) v.s. store (C++11) atomically replaces the value of the atomic object with a non-atomic argument (public member function)
  4. operator T() loads a value from an atomic object (public member function) v.s. load (C++11) atomically obtains the value of the atomic object (public member function).
  5. operator+= v.s. fetch_add
  6. operator-= v.s. fetch_sub
  7. operator&= v.s. fetch_and
  8. operator|= v.s. fetch_or
  9. operator^= v.s. fetch_xor
  10. What's the downside of declare a variable as atomic v.s. a non-atomic variable. For example, what's the downside of std::atomic<int> x v.s. int x? In other words, how much is the overhead of an atomic variable?
  11. Which one has more overhead? An atomic variable, v.s. a normal variable protected by a mutex?

Here is the reference to my quesitons. http://en.cppreference.com/w/cpp/atomic/atomic

Improve this question
1
  • I think it would be worth your time studying a particular architectures atomic cpu instructions and memory barriers to get a better understanding of the internals of how atomic operations are implemented. See here for a starting point on x86: mohawksoft.org/?q=node/78, and lookup the Intel manual as a reference: intel.com/content/www/us/en/processors/… Commented Nov 5, 2012 at 11:44

3 Answers 3

Reset to default
10

Not an expert, but I'll try:

  1. The specializations (for built-in types such as int) contain additional operations such as fetch_add. Non-specialized forms (user defined types) will not contain these.
  2. operator= returns its argument, store does not. Also, non-operators allow you to specify a memory order. The standard says operator= is defined in terms of store.
  3. Same as above, although it returns the value of load.
  4. Same as above
  5. Same as above
  6. Same as above
  7. Same as above
  8. Same as above
  9. Same as above
  10. They do different things. It's undefined behavior to use an int in the way you would use std::atomic_int.
  11. You can assume the overhead is int <= std::atomic <= int and std::mutex where <= means 'less overhead'. So it's likely better than locking with a mutex (especially for built-in types), but worse than int.
Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

Thank you for you reply, can you explain what is memory_order?I found reference and few examples here, en.cppreference.com/w/cpp/atomic/memory_order. But don't really understand. Thanks.
@2607 "memory_order" is very hard to explain and to understand. To a first approximation, all you have to know is that you should always use seq_cst, which is the default anyway. To a second approximation, think of each atomic access as protected by a mutex that is acquired before the access and released after. As with any critical section, other program operations can be shifted into the critical section but not out of it. acquire semantics allow other operations to be shifted down but not up; release semantics allow shifting up but not down. To a third approximation, I don't know.
std::atomic is designed to be overhead-free compared with a simple integer when circumstances permit (as e.g. in case of an atomic store with relaxed memory order on an x86). Another important information in this context is that std::atomic may implement arithmetic operations in an interlocked fashion on platforms that do not support these operations natively. So in general, given enough contention the second inequality operator in this post may (or may not) turn around.
10
+100

What's the difference between specialized and non-specialized atomic member functions?

As can be seen in the synposis of these classes on the standard (§29.5), there are three different sets of member functions:

  • the most generic one provides only store, load, exchange, and compare-exchange operations;
  • the specializations for integral types provide atomic arithmetic and bitwise operations, in addition to the generic ones;
  • the specialization for pointers provides pointer arithmetic operations in addition to the generic ones.

What's the difference (if there is any) between following functions?

operator= stores a value into an atomic object (public member function) v.s. store (C++11) atomically replaces the value of the atomic object with a non-atomic argument (public member function)

(...)

The main functional difference is that the non-operator versions (§29.6.5, paragraphs 9-17 and more) have an extra parameter for specifying the desired memory ordering (§29.3/1). The operator versions use the sequential consistency memory ordering:

void A::store(C desired, memory_order order = memory_order_seq_cst) volatile noexcept;
void A::store(C desired, memory_order order = memory_order_seq_cst) noexcept;

Requires: The order argument shall not be memory_order_consume, memory_order_acquire, nor memory_order_acq_rel.

Effects: Atomically replaces the value pointed to by object or by this with the value of desired. Memory is affected according to the value of order.

C A::operator=(C desired) volatile noexcept;
C A::operator=(C desired) noexcept;

Effects: store(desired)

Returns: desired

The non-operator forms are advantageous because sequential consistency is not always necessary, and it is potentially more expensive than the other memory orderings. With careful analysis one can find out what are the minimal guarantees needed for correct operation and select one of the less restrictive memory orderings, giving more leeway to the optimizer.

What's the downside of declare a variable as atomic v.s. a non-atomic variable. For example, what's the downside of std::atomic<int> x v.s. int x? In other words, how much is the overhead of an atomic variable?

Using an atomic variable when a regular variable would suffice limits the number of possible optimizations, because atomic variables impose additional constraints of indivisibility and (possibly) memory ordering.

Using a regular variable when an atomic variable is needed may introduce data races, and that makes the behaviour undefined (§1.10/21):

The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior.

The overhead of an atomic variable is a matter of quality of implementation. Ideally, an atomic variable has zero overhead when you need atomic operations. When you don't need atomic operations, whatever overhead it may have is irrelevant: you just use a regular variable.

Which one has more overhead? An atomic variable, v.s. a normal variable protected by a mutex?

There's no reason for an atomic variable to have more overhead than a normal variable protected by a mutex: worst case scenario, the atomic variable is implemented just like that. But there is a possibility that the atomic variable is lock-free, which would involve less overhead. This property can be ascertained with the functions described in the standard in §29.6.5/7:

bool atomic_is_lock_free(const volatile A *object) noexcept;
bool atomic_is_lock_free(const A *object) noexcept;
bool A::is_lock_free() const volatile noexcept;
bool A::is_lock_free() const noexcept;

Returns: True if the object’s operations are lock-free, false otherwise.

Improve this answer

Comments

0

I'm not an expert on this stuff, but if I understand correctly the non-specialized operations in your reference do one thing atomically, load, store, replace, etc.

The specialized function do two things atomically, that is they modify and then return an atomic object in such a way that both operations happen before any other thread could mess with them.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.