问题描述
在 boost::atomic 并在 std::atomic 上使我感到困惑的是atomic接口是否应该支持非平凡类型?
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?
也就是说，由于给定的(value-)类型只能通过将读取/写入包含在完整的互斥锁中来进行写入/读取，因为它具有非平凡的copy-ctor/assignment运算符，应该认为这是由std::atomic支持(升压明显表明它是UB).
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?
注意:之所以遇到这个问题，是因为我有一个跨线程回调对象boost::function<bool (void)> simpleFn;，需要自动设置/重置.拥有一个单独的互斥体/关键部分，甚至用简单的设置将它们都包裹在类似原子的帮助程序类型中，看起来似乎很容易，但是有没有开箱即用的东西?
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?
推荐答案
Arne的答案已经指出，该标准要求std::atomic的琐碎可复制类型.
Arne's answer already points out that the Standard requires trivially copyable types for std::atomic.
以下是一些基本原理，为什么原子可能首先不是解决问题的正确工具:原子是在C ++中构建线程安全数据结构的基本构建基元.它们应该是构建更强大的数据结构(例如线程安全的容器)的最低级别的构建基块.
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.
尤其是，原子通常用于构建无锁数据结构.为了锁定数据结构，像std::mutex和std::condition_variable这样的原语是一种更好的匹配方式，仅是因为很难在不引入大量等待的情况下用原子编写阻塞代码非常困难.
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.
因此，当您想到std::atomic时，第一个关联应为无锁(尽管事实上，大多数原子类型在技术上都允许具有阻塞实现).您所描述的是一个简单的基于锁的并发数据结构，因此从概念的角度来看，将其包装在原子中应该已经感觉不对.
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.
不幸的是，目前尚不清楚如何用这种语言来表示数据结构是线程安全的(我想这首先是您使用atomic的主要意图).赫伯·萨特(Herb Sutter)有一些有趣的想法，但是我想现在我们只需要接受一个事实，那就是我们必须依靠文档来交流某些数据结构在线程安全方面的行为.
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.
这篇关于具有非平凡类型的C ++原子?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！