blocks|key|505479|text|不，如果您不知道它将如何使用，您应该使用memory_order_seq_cst来确保安全。如果使用memory_order_relaxed，您可能会遇到重新排序指令的问题。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|505480|entityMap^0|K|K|1E|K|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

No, if you don't know how it will be used, you should use <code>memory_order_seq_cst</code> to be safe. If you use <code>memory_order_relaxed</code>, you could run into issues with instructions being reordered.

blocks|key|2931704|text|如果您的复制操作应该与其他线程上的其他操作同步，则只需要比memory_order_relaxed更强的内存排序。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2931705|然而，这种情况几乎从未发生过，因为线程安全的复制构造函数几乎总是需要一些外部同步或额外的互斥对象。|2931706|entityMap^0|T|K|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

You only need a stronger memory ordering than <code>memory_order_relaxed</code>, if your copy operation is supposed to synchronize with other operations on a different thread. 
However, this is almost never the case, as a thread safe copy constructor will almost always require some external synchronization or an extra mutex anyway.

blocks|key|1852640|text|std::atomic<T>模板删除它的复制构造函数，因为atomics用于共享状态，所以将它们复制到另一个原子通常不是您想要的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1852641|删除复制构造函数会迫使类的用户考虑他们正在做什么，并记录他们正在执行一个值的原子加载，然后将该副本传递到其他地方。(如atomic<some_struct>+var1+(var2.load()))。请参阅会员？|1852642|std::atomic<T>+本身并不是原子的的构造函数，所以担心在构造函数中为它排序是没有意义的(除非构造函数调用了一组其他函数，并将mInt的地址放在另一个线程可以得到的某个地方.)|1852643|更好的是，使用复制的值作为初始化器，而不是执行原子存储。(另见复制构造器中原子的非锁定复制方法)。|1852644|我认为这可能是一个问题的唯一方法是，如果您正在做一些已经没有定义的行为，比如使用new在一个已经共享的位置构造一个新的Foo对象，在这样做的时候可以由其他线程读取/编写。这显然是疯了，所以别那么做。|1852645|让类的内存排序行为与std::atomic<T>的构造函数匹配(即没有用于存储初始化程序)似乎是个好主意。|1852646|只有调用方知道来自源操作数的加载是否需要顺序一致性。因此，您应该让调用方通过接受内存顺序参数(为了与default=seq_cst的一致性，而不是因为这是任何人在这种情况下可能想要的)进行选择。是的，这是合法的C%2B%2B：复制带有默认参数的构造函数|1852647|#include+<atomic>

struct+Foo
{
++++std::atomic<int>+mInt;

++++Foo()+{}
++++Foo(const+Foo&+pOther,+std::memory_order+order+=+std::memory_order_seq_cst)
++++++++:+mInt(pOther.mInt.load(order))
++++{}
};|code-block|syntax|javascript|1852648|这是我所期望的编译方式:为加载进行排序，但不对存储进行排序。(例如，查看ARM64的asm输出显示，load使用ldar进行获取加载，但是存储只是一个简单的str)。|1852649|我用调用方(戈德波特编译器浏览器)测试了它，它在堆栈上构造了一个地址，然后将其地址传递给一个非内联函数，该函数可能使其他线程可以使用该地址。所以它不能优化。|1852650|void+extf(Foo+&);++++//+non-inline+function

void+test(const+Foo+*p)+{
++++Foo+tmp(*p);
++++extf(tmp);
}|1852651|extf()+为使其他线程可以使用该地址所做的任何操作，都应该使用一个发布存储，以确保看到该地址的任何其他线程都会看到一个构造正确的+Foo**.**+--这是一个正常的要求，也是为什么初始化器不是原子的完全正确的原因。|BOLD|1852652|请注意，不可能以单个原子操作(在C%2B%2B11或我所知道的任何硬件上)在两个不同的内存位置之间移动，所以强排序不太可能有用。|1852653|即使定义这样的移动是否是原子的，也是有问题的，因为原子性只存在于观察者的眼里。因为不可能同时观察两个内存位置，这是一个毫无意义的概念。(除非它们是相邻的，并且只需一个原子负载就可以得到它们)。|1852654|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/14182258/c11-write-move-constructor-with-atomicbool-member/14183013#14183013|1|http://en.cppreference.com/w/cpp/atomic/atomic/atomic|2|https://stackoverflow.com/questions/33723142/nonlocking-way-to-copy-atomics-in-copy-constructor|3|http://en.cppreference.com/w/cpp/language/new|4|https://stackoverflow.com/questions/2787569/copy-constructor-with-default-arguments|5|https://gcc.godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(j:1,source:'#include%2B%253Catomic%253Estruct%2BFoo{%2B%2B%2B%2Bstd::atomic%253Cint%253E%2BmInt;%2B%2B%2B%2BFoo()%2B{}%2B%2B%2B%2BFoo(const%2BFoo&%2BpOther,%2Bstd::memory_order%2Border%2B=%2Bstd::memory_order_seq_cst)%2B%2B%2B%2B%2B%2B%2B%2B:%2BmInt(pOther.mInt.load(order))%2B%2B%2B%2B{}};void%2Bextf(Foo%2B&);void%2Btest(const%2BFoo%2B*p){%2B%2B%2B%2BFoo%2Btmp(*p);%2B%2B%2B%2Bextf(tmp);}'),l:'5',n:'0',o:'C%2B%2B%2Bsource%2B#1',t:'0')),k:33.344394394597536,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:arm64g630,filters:(___0:(),b:'0',commentOnly:'0',directives:'0',intel:'0',jquery:'3.2.1',length:1,prevObject:(___0:(sizzle1504571495915:(undefined:(legend:!(5,0,'1')))),length:1,prevObject:(___0:(jQuery321073054571485486371:(display:''),sizzle1504571495915:(undefined:(legend:!(5,0,'1')))),length:1))),options:'-std=gnu%2B%2B11%2B-O3%2B-Wall%2B-Wextra',source:1),l:'5',n:'0',o:'ARM64%2Bgcc%2B6.3.0%2B(Editor%2B#1,%2BCompiler%2B#1)',t:'0')),header:(),k:32.91585939773626,l:'4',m:100,n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:clang_trunk,filters:(b:'0',commentOnly:'0',directives:'0',intel:'0'),options:'-stdlib=libc%2B%2B%2B-std=gnu%2B%2B11%2B-O3%2B-Wall%2B-Wextra',source:1),l:'5',n:'0',o:'x86-64%2Bclang%2B(trunk)%2B(Editor%2B#1,%2BCompiler%2B#2)',t:'0')),k:33.7397462076662,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4^0|0|E|0|1N|12|2U|3|0|0|0|E|1W|4|F|8|1|0|V|G|2|0|14|3|1N|3|14|3|3|0|A|E|0|31|D|4|0|0|1K|4|26|3|0|5|C|5|0|0|0|6|7|1N|1V|5|0|6|1V|3|0|0|0^^$0|@$1|2|3|4|5|6|7|1R|8|@$9|1S|A|1T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1U|8|@$9|1V|A|1W|B|C]]|D|@$9|1X|A|1Y|1|1Z]]|E|$]]|$1|H|3|I|5|6|7|20|8|@$9|21|A|22|B|C]|$9|23|A|24|B|C]]|D|@$9|25|A|26|1|27]]|E|$]]|$1|J|3|K|5|6|7|28|8|@]|D|@$9|29|A|2A|1|2B]]|E|$]]|$1|L|3|M|5|6|7|2C|8|@$9|2D|A|2E|B|C]|$9|2F|A|2G|B|C]]|D|@$9|2H|A|2I|1|2J]]|E|$]]|$1|N|3|O|5|6|7|2K|8|@$9|2L|A|2M|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|2N|8|@]|D|@$9|2O|A|2P|1|2Q]]|E|$]]|$1|R|3|S|5|T|7|2R|8|@]|D|@]|E|$U|V]]|$1|W|3|X|5|6|7|2S|8|@$9|2T|A|2U|B|C]|$9|2V|A|2W|B|C]]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|2X|8|@]|D|@$9|2Y|A|2Z|1|30]]|E|$]]|$1|10|3|11|5|T|7|31|8|@]|D|@]|E|$U|V]]|$1|12|3|13|5|6|7|32|8|@$9|33|A|34|B|14]|$9|35|A|36|B|14]|$9|37|A|38|B|14]|$9|39|A|3A|B|C]|$9|3B|A|3C|B|C]]|D|@]|E|$]]|$1|15|3|16|5|6|7|3D|8|@]|D|@]|E|$]]|$1|17|3|18|5|6|7|3E|8|@]|D|@]|E|$]]|$1|19|3|-4|5|6|7|3F|8|@]|D|@]|E|$]]]|1A|$1B|$5|1C|1D|1E|E|$1F|1G]]|1H|$5|1C|1D|1E|E|$1F|1I]]|1J|$5|1C|1D|1E|E|$1F|1K]]|1L|$5|1C|1D|1E|E|$1F|1M]]|1N|$5|1C|1D|1E|E|$1F|1O]]|1P|$5|1C|1D|1E|E|$1F|1Q]]]]

The <code>std::atomic&lt;T&gt;</code> template deletes its copy-constructor, because atomics are for shared state, so copying them to another atomic is usually not what you want.

Deleting the copy-constructor forces users of your class to think about what they're doing, and document that they're doing an atomic-load of one value and then passing that copy to somewhere else. (e.g. <code>atomic&lt;some_struct&gt; var1 (var2.load())</code>). See <a href="https://stackoverflow.com/questions/14182258/c11-write-move-constructor-with-atomicbool-member/14183013#14183013">C++11: write move constructor with atomic&lt;bool&gt; member?</a>

<hr>

The constructor for <code>std::atomic&lt;T&gt;</code> <a href="http://en.cppreference.com/w/cpp/atomic/atomic/atomic" rel="nofollow noreferrer">is not itself atomic</a>, so it makes little sense to worry about the ordering of a store to it in your constructor (unless your constructor called a bunch of other functions and put the address of <code>mInt</code> somewhere that another thread could get it...)

Even better, use the copied value as an initializer, instead of doing an atomic store at all. (See also <a href="https://stackoverflow.com/questions/33723142/nonlocking-way-to-copy-atomics-in-copy-constructor">Nonlocking Way to Copy Atomics in Copy Constructor</a>).

I think the only way this could be a problem is if you were doing something that's already undefined-behaviour, like using <a href="http://en.cppreference.com/w/cpp/language/new" rel="nofollow noreferrer">placement-<code>new</code></a> to construct a new <code>Foo</code> object in an already-shared location that could be read/written by other threads as you did this. This is obviously insane, so don't do that.

Having your class's memory-ordering behaviour match <code>std::atomic&lt;T&gt;</code>'s constructor (i.e. none for storing the initializer) seems like a good idea.

<hr>

Only the caller knows whether sequential-consistency is required for the load from the source operand. Thus, you should let the caller choose by accepting a memory-order argument, with default=seq_cst (for consistency with <code>std::atomic</code>, not because that's what anyone is likely to want for this case). And yes, this is legal C++: <a href="https://stackoverflow.com/questions/2787569/copy-constructor-with-default-arguments">copy constructor with default arguments</a>

<pre><code>#include &lt;atomic&gt;

struct Foo
{
 std::atomic&lt;int&gt; mInt;

 Foo() {}
 Foo(const Foo&amp; pOther, std::memory_order order = std::memory_order_seq_cst)
 : mInt(pOther.mInt.load(order))
 {}
};
</code></pre>

This compiles the way I expected: with ordering for the load but no ordering for the store. (e.g. looking at the asm output for ARM64 shows that the load uses <code>ldar</code> to do an acquire-load, but the store is just a simple <code>str</code>).

I tested it with this caller <a href="https://gcc.godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(j:1,source:&#39;%23include+%3Catomic%3E%0A%0Astruct+Foo%0A%7B%0A++++std::atomic%3Cint%3E+mInt%3B%0A%0A++++Foo()+%7B%7D%0A++++Foo(const+Foo%26+pOther,+std::memory_order+order+%3D+std::memory_order_seq_cst)%0A++++++++:+mInt(pOther.mInt.load(order))%0A++++%7B%7D%0A%7D%3B%0A%0Avoid+extf(Foo+%26)%3B%0A%0Avoid+test(const+Foo+*p)%0A%7B%0A++++Foo+tmp(*p)%3B%0A++++extf(tmp)%3B%0A%7D%0A&#39;),l:&#39;5&#39;,n:&#39;0&#39;,o:&#39;C%2B%2B+source+%231&#39;,t:&#39;0&#39;)),k:33.344394394597536,l:&#39;4&#39;,n:&#39;0&#39;,o:&#39;&#39;,s:0,t:&#39;0&#39;),(g:!((h:compiler,i:(compiler:arm64g630,filters:(___0:(),b:&#39;0&#39;,commentOnly:&#39;0&#39;,directives:&#39;0&#39;,intel:&#39;0&#39;,jquery:&#39;3.2.1&#39;,length:1,prevObject:(___0:(sizzle1504571495915:(undefined:(legend:!(5,0,&#39;1&#39;)))),length:1,prevObject:(___0:(jQuery321073054571485486371:(display:&#39;&#39;),sizzle1504571495915:(undefined:(legend:!(5,0,&#39;1&#39;)))),length:1))),options:&#39;-std%3Dgnu%2B%2B11+-O3+-Wall+-Wextra&#39;,source:1),l:&#39;5&#39;,n:&#39;0&#39;,o:&#39;ARM64+gcc+6.3.0+(Editor+%231,+Compiler+%231)&#39;,t:&#39;0&#39;)),header:(),k:32.91585939773626,l:&#39;4&#39;,m:100,n:&#39;0&#39;,o:&#39;&#39;,s:0,t:&#39;0&#39;),(g:!((h:compiler,i:(compiler:clang_trunk,filters:(b:&#39;0&#39;,commentOnly:&#39;0&#39;,directives:&#39;0&#39;,intel:&#39;0&#39;),options:&#39;-stdlib%3Dlibc%2B%2B+-std%3Dgnu%2B%2B11+-O3+-Wall+-Wextra&#39;,source:1),l:&#39;5&#39;,n:&#39;0&#39;,o:&#39;x86-64+clang+(trunk)+(Editor+%231,+Compiler+%232)&#39;,t:&#39;0&#39;)),k:33.7397462076662,l:&#39;4&#39;,n:&#39;0&#39;,o:&#39;&#39;,s:0,t:&#39;0&#39;)),l:&#39;2&#39;,n:&#39;0&#39;,o:&#39;&#39;,t:&#39;0&#39;)),version:4" rel="nofollow noreferrer">(Godbolt compiler explorer)</a> which constructs one on the stack and then passes its address to a non-inline function that might make that address available to other threads. So it can't optimize away.

<pre><code>void extf(Foo &amp;); // non-inline function

void test(const Foo *p) {
 Foo tmp(*p);
 extf(tmp);
}
</code></pre>

Whatever <code>extf()</code> does to make the address available to other threads should use a release-store, which ensures that any other thread which sees that address will see a properly-constructed <code>Foo</code>. This is a normal requirement, and is why it's totally fine that the initializer isn't even atomic.

<hr>

Note that it's impossible to do a move between two different memory locations as a single atomic operation (in C++11 or on any hardware I'm aware of), so it's unlikely that a strong ordering will be useful.

Even defining whether such a move is atomic or not is problematic, because atomicity only exists in the eyes of an observer. Since it's impossible to observe two memory locations at the same time it's a meaningless concept. (Unless they're adjacent and you can get them both with a single atomic load).

I have a class with an atomic member and i want to write a copy constructor:

<pre><code>struct Foo
{
 std::atomic&lt;int&gt; mInt;

 Foo() {}
 Foo(const Foo&amp; pOther)
 {
 std::atomic_store(mInt, std::atomic_load(pOther.mInt, memory_order_relaxed), memory_order_relaxed);
 }
};
</code></pre>

But i don't know which ordering i must use, because i don't know where and when this copy constructor will be called.

Can i use <code>relaxed</code> ordering for copy constructor and assignment operator?

Copy constructor for classes with atomic member

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有一个带有原子成员的类，我想编写一个复制构造函数：struct Foo{ std::atomic<int> mInt; Foo() {} Foo(const Foo& pOther) { std::atomic_store(mInt, std::atomic_load(pOthe...

问为具有原子成员的类复制构造函数
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为具有原子成员的类复制构造函数EN