8

Reading the docs on boost::atomic and on std::atomic leaves me confused as to whether the atomic interface is supposed to support non-trivial types?

That is, given a (value-)type that can only be written/read by enclosing the read/write in a full mutex, because it has a non-trivial copy-ctor/assignment operator, is this supposed to be supported by std::atomic (as boost clearly states that it is UB).

Am I supposed to provide the specialization the docs talk about myself for non-trivial types?

Note: I was hitting on this because I have a cross-thread callback object boost::function<bool (void)> simpleFn; that needs to be set/reset atomically. Having a separate mutex / critical section or even wrapping both in a atomic-like helper type with simple set and get seem easy enough, but is there anything out of the box?

Martin Ba
  • 37,187
  • 33
  • 183
  • 337
  • Related: http://stackoverflow.com/questions/13885617/how-to-use-stdatomic-effectively-for-non-primitive-types – Martin Ba Aug 24 '16 at 13:40

2 Answers2

6

Arne's answer already points out that the Standard requires trivially copyable types for std::atomic.

Here's some rationale why atomics might not be the right tool for your problem in the first place: Atomics are the fundamental building primitives for building thread-safe data structures in C++. They are supposed to be the lowest-level building blocks for constructing more powerful data structures like thread-safe containers.

In particular, atomics are usually used for building lock-free data structures. For locking data structures primitives like std::mutex and std::condition_variable are a way better match, if only for the fact that it is very hard to write blocking code with atomics without introducing lots of busy waiting.

So when you think of std::atomic the first association should be lock-free (despite the fact that most of the atomic types are technically allowed to have blocking implementations). What you describe is a simple lock-based concurrent data structure, so wrapping it in an atomic should already feel wrong from a conceptual point of view.

Unfortunately, it is currently not clear how to express in the language that a data structure is thread-safe (which I guess was your primary intent for using atomic in the first place). Herb Sutter had some interesting ideas on this issue, but I guess for now we simply have to accept the fact that we have to rely on documentation to communicate how certain data structures behave with regards to thread-safety.

Martin Ba
  • 37,187
  • 33
  • 183
  • 337
ComicSansMS
  • 51,484
  • 14
  • 155
  • 166
  • You can say all that, but they explicitly specialized `std::atomic` for a reason. Now people who have their own refcounting types (like `boost::intrusive_ptr`) can't just use atomic the same way as for `std::shared_ptr`. – user541686 Nov 02 '21 at 10:01
  • @user541686 Note though that `shared_ptr` already had an atomic interface in C++11, which was intended to be lock-free on platforms where it's possible to implement them as such. This is not the same as just wrapping your run-of-the-mill class type in a `std::atomic` template - a specific set of lock-free operations, which are not part of the `std::shared_ptr` class itself are required to make this work. – ComicSansMS Nov 02 '21 at 10:12
  • What I'm pointing out is that the generic implementation of atomics that already exists for trivial types would work just fine for nontrivial smart pointers too. It might not be exactly lock-free, but you could perfectly sensibly still use it with other smart pointers if they weren't needlessly prohibited, and if you found it to be a performance bottleneck you could then try to specialize std::atomic with a better implementation. Instead of the current situation where it's outright impossible to use the default implementation in that same situation. – user541686 Nov 03 '21 at 02:51
  • It's particularly sad that even `std::exception_ptr` can't be stored in an atomic despite `std::shared_ptr` being already supported. – user541686 Nov 03 '21 at 02:52
4

The standard specifies (§29.5,1) that

The type of the template argument T shall be trivially copyable

Meaning no, you cannot use types with non-trivial copy-ctor or assignment-op.

However, like with any template in namespace std, you are free to specialize the template for any type that it has not been specialized for by the implementation. So if you really want to use std::atomic<MyNonTriviallyCopyableType>, you have to provide the specialization yourself. How that specialization behaves is up to you, meaning, you are free to blow off your leg or the leg of anyone using that specialization, because it's just outside the scope of the standard.

Arne Mertz
  • 24,171
  • 3
  • 51
  • 90