This is a bit of a two part question, all about the atomicity of std::shared_ptr:
这是一个由两部分组成的问题，都是关于std: shared_ptr的原子性:
1. As far as I can tell, std::shared_ptr is the only smart pointer in <memory> that's atomic. I'm wondering if there is a non-atomic version of std::shared_ptr available (I can't see anything in <memory>, so I'm also open to suggestions outside of the standard, like those in Boost). I know boost::shared_ptr is also atomic (if BOOST_SP_DISABLE_THREADS isn't defined), but maybe there's another alternative? I'm looking for something that has the same semantics as std::shared_ptr, but without the atomicity.
1。据我所知，std::shared_ptr是
2. I understand why std::shared_ptr is atomic; it's kinda nice. However, it's not nice for every situation, and C++ has historically had the mantra of "only pay for what you use." If I'm not using multiple threads, or if I am using multiple threads but am not sharing pointer ownership across threads, an atomic smart pointer is overkill. My second question is why wasn't a non-atomic version of std::shared_ptr provided in C++11? (assuming there is a why) (if the answer is simply "a non-atomic version was simply never considered" or "no one ever asked for a non-atomic version" that's fine!).
2。我理解为什么std::shared_ptr是原子的;这是挺不错的。然而，它并不适用于每一种情况，而且c++历来都有“只为你使用的东西付费”的口号。如果我没有使用多个线程，或者我正在使用多个线程，但是没有跨线程共享指针所有权，那么原子智能指针就会被过度使用。我的第二个问题是为什么在c++ 11中没有提供std: shared_ptr的非原子版本?(假设有一个原因)(如果答案仅仅是“没有考虑过非原子版本”或“没有人要求过非原子版本”，那就可以了!)
With question #2, I'm wondering if someone ever proposed a non-atomic version of shared_ptr (either to Boost or the standards committee) (not to replace the atomic version of shared_ptr, but to coexist with it) and it was shot down for a specific reason.
在问题2中，我想知道是否有人提出过shared_ptr的非原子版本(要么是Boost，要么是标准委员会)(不是为了替换shared_ptr的原子版本，而是为了与之共存)，但由于特定的原因，这个版本被否决了。
4 个解决方案
#1
83
1. I'm wondering if there is a non-atomic version of std::shared_ptr available
1。我想知道是否有一个非原子版本的std::shared_ptr。
Not provided by the standard. There may well be one provided by a "3rd party" library. Indeed, prior to C++11, and prior to Boost, it seemed like everyone wrote their own reference counted smart pointer (including myself).
本标准未规定。可能会有一个由“第三方”图书馆提供。实际上，在c++ 11之前，在Boost之前，似乎每个人都编写了自己的引用计数智能指针(包括我自己)。
2. My second question is why wasn't a non-atomic version of std::shared_ptr provided in C++11?
2。我的第二个问题是，为什么非原子版本的std::shared_ptr在c++ 11中提供?
This question was discussed at the Rapperswil meeting in 2010. The subject was introduced by a National Body Comment #20 by Switzerland. There were strong arguments on both sides of the debate, including those you provide in your question. However, at the end of the discussion, the vote was overwhelmingly (but not unanimous) against adding an unsynchronized (non-atomic) version of shared_ptr.
这个问题在2010年的Rapperswil会议上被讨论过。瑞士国家机构第20号评论介绍了这个话题。辩论双方都有有力的论点，包括你在问题中提出的论点。然而，在讨论结束时，压倒性地(但并非一致地)投票反对添加shared_ptr的非同步(非原子)版本。
Arguments against included:
反对包括:
-
Code written with the unsynchronized shared_ptr may end up being used in threaded code down the road, ending up causing difficult to debug problems with no warning.
使用非同步shared_ptr编写的代码最终可能会被用于线程代码，最终导致在没有警告的情况下难以调试问题。
-
Having one "universal" shared_ptr that is the "one way" to traffic in reference counting has benefits: From the original proposal:
拥有一个“通用”shared_ptr，即引用计数的“单向”流量，有好处:
Has the same object type regardless of features used, greatly facilitating interoperability between libraries, including third-party libraries.
无论使用什么特性，都具有相同的对象类型，这极大地促进了库之间的互操作性，包括第三方库。
-
The cost of the atomics, while not zero, is not overwhelming. The cost is mitigated by the use of move construction and move assignment which do not need to use atomic operations. Such operations are commonly used in
vector<shared_ptr<T>>erase and insert.原子的成本虽然不是零，但也不是压倒性的。使用不需要使用原子操作的移动构造和移动分配可以降低成本。这种操作通常用于向量
>擦除和插入。 -
Nothing prohibits people from writing their own non-atomic reference-counted smart pointer if that's really what they want to do.
没有什么能阻止人们编写他们自己的非原子引用计数智能指针，如果这是他们真正想做的。
The final word from the LWG in Rapperswil that day was:
当天，来自Rapperswil的LWG的最后一句话是:
Reject CH 20. No consensus to make a change at this time.
拒绝CH 20。目前还没有做出改变的共识。
#2
41
Howard's answered the question well already, and Nicol made some good points about the benefits of having a single standard shared pointer type, rather than lots of incompatible ones.
Howard已经很好地回答了这个问题，Nicol提出了一些关于拥有一个标准共享指针类型的好处，而不是许多不兼容的指针类型。
While I completely agree with the committee's decision, I do think there is some benefit to using an unsynchronized shared_ptr-like type in special cases, so I've investigated the topic a few times.
虽然我完全同意委员会的决定，但我确实认为在特殊情况下使用非同步shared_ptrlike类型有一些好处，因此我对这个主题进行了几次调查。
If I'm not using multiple threads, or if I am using multiple threads but am not sharing pointer ownership across threads, an atomic smart pointer is overkill.
如果我没有使用多个线程，或者我正在使用多个线程，但是没有跨线程共享指针所有权，那么原子智能指针就会被过度使用。
With GCC when your program doesn't use multiple threads shared_ptr doesn't use atomic ops for the refcount. This is done by updating the reference counts via wrapper functions that detect whether the program is multithreaded (on GNU/Linux this is done simply by detecting whether the program links to libpthread.so) and dispatch to atomic or non-atomic operations accordingly.
使用GCC时，当程序不使用多线程shared_ptr时，refcount就不使用原子操作。这是通过通过包装器函数更新引用计数来实现的，它可以检测程序是多线程的(在GNU/Linux上，这仅仅是通过检测程序链接到libpthreadso)，并相应地发送到原子或非原子操作。
I realised many years ago that because GCC's shared_ptr<T> is implemented in terms of a __shared_ptr<T, _LockPolicy> base class, it's possible to use the base class with the single-threaded locking policy even in multithreaded code, by explicitly using __shared_ptr<T, __gnu_cxx::_S_single>. Unfortunately because that wasn't an intended use case it didn't quite work optimally before GCC 4.9, and some operations still used the wrapper functions and so dispatched to atomic operations even though you've explicitly requested the _S_single policy. See point (2) at http://gcc.gnu.org/ml/libstdc++/2007-10/msg00180.html for more details and a patch to GCC to allow the non-atomic implementation to be used even in multithreaded apps. I sat on that patch for years but I finally committed it for GCC 4.9, which allows you to use an alias template like this to define a shared pointer type that is not thread-safe, but is slightly faster:
我多年前就意识到，因为GCC的shared_ptr
template<typename T>
using shared_ptr_unsynchronized = std::__shared_ptr<T, __gnu_cxx::_S_single>;
This type would not be interoperable with std::shared_ptr<T> and would only be safe to use when it is guaranteed that the shared_ptr_unsynchronized objects would never be shared between threads without additional user-provided synchronization.
这种类型不能与std: shared_ptr
This is of course completely non-portable, but sometimes that's OK. With the right preprocessor hacks your code would still work fine with other implementations if shared_ptr_unsynchronized<T> is an alias for shared_ptr<T>, it would just be a little faster with GCC.
这当然是完全不可移植的，但有时也可以。如果使用正确的预处理器hacks，如果shared_ptr_unsynchronized
If you're using a GCC before 4.9 you could use that by adding the _Sp_counted_base<_S_single> explicit specializations to your own code (and ensuring noone ever instantiates __shared_ptr<T, _S_single> without including the specializations, to avoid ODR violations.) Adding such specializations of std types is technically undefined, but would work in practice, because in this case there's no difference between me adding the specializations to GCC or you adding them to your own code.
如果您在4.9之前使用GCC，您可以将_Sp_counted_base<_S_single>显式专门化添加到您自己的代码中(并确保没有人实例化__shared_ptr
#3
20
My second question is why wasn't an atomic version of std::shared_ptr provided in C++11? (assuming there is a why).
我的第二个问题是，为什么std的原子版本不是:shared_ptr在c++ 11中提供的?(假设有原因的话)。
One could just as easily ask why there isn't an intrusive pointer, or any number of other possible variations of shared pointers one could have.
人们也可以很容易地问为什么没有插入指针，或者有任何其他可能的共享指针变体。
The design of shared_ptr, handed down from Boost, has been to create a minimum standard lingua-franca of smart pointers. That, generally speaking, you can just pull this down off the wall and use it. It's something that would be used generally, across a wide variety of applications. You can put it in an interface, and odds are good people will be willing to use it.
shared_ptr是由Boost提供的，其设计是创建一个智能指针的最小标准通用语言。一般来说，你可以把它从墙上拉下来用。它将被广泛应用于各种各样的应用中。你可以把它放到一个界面中，很有可能会有好的人愿意使用它。
Threading is only going to get more prevalent in the future. Indeed, as time passes, threading will generally be one of the primary means to achieve performance. Requiring the basic smart pointer to do the bare minimum needed to support threading facilitates this reality.
线程化只会在将来变得更加普遍。的确，随着时间的推移，线程化通常将是实现性能的主要手段之一。需要基本的智能指针来完成支持线程所需的最低限度，这有助于实现这一现实。
Dumping a half-dozen smart pointers with minor variations between them into the standard, or even worse a policy-based smart pointer, would have been terrible. Everyone would pick the pointer they like best and forswear all others. Nobody would be able to communicate with anyone else. It'd be like the current situations with C++ strings, where everyone has their own type. Only far worse, because interoperation with strings is a lot easier than interoperation between smart pointer classes.
将六个智能指针(它们之间的差异很小)转储到标准中，甚至是基于策略的智能指针，都是很糟糕的。每个人都会选择他们最喜欢的指针，并放弃所有其他的。没人能和别人交流。就像当前的c++字符串，每个人都有自己的类型。更糟糕的是，因为使用字符串进行互操作比在智能指针类之间进行互操作要容易得多。
Boost, and by extension the committee, picked a specific smart pointer to use. It provided a good balance of features and was widely and commonly used in practice.
Boost和委员会进一步选择了一个特定的智能指针来使用。它提供了良好的功能平衡，并在实践中广泛和普遍使用。
std::vector has some inefficiencies compared to naked arrays in some corner cases too. It has some limitations; some uses really want to have a hard limit on the size of a vector, without using a throwing allocator. However, the committee didn't design vector to be everything for everyone. It was designed to be a good default for most applications. Those for whom it can't work can just write an alternative that suites their needs.
在某些情况下，向量与裸数组相比也有一些低效率。它有一些局限性;有些应用真的想要对向量的大小有一个硬限制，而不需要使用抛出分配器。然而，委员会并没有把向量设计成每个人的一切。它被设计成大多数应用程序的良好默认值。对于那些无法工作的人来说，可以编写一个满足他们需求的替代方案。
Just as you can for a smart pointer if shared_ptr's atomicity is a burden. Then again, one might also consider not copying them around so much.
就像对于智能指针一样，如果shared_ptr的原子性是一个负担。同样，你也可以考虑不经常复制它们。
#4
4
I am preparing a talk on shared_ptr at work. I have been using a modified boost shared_ptr with avoid separate malloc (like what make_shared can do) and a template param for lock policy like shared_ptr_unsynchronized mentioned above. I am using the program from
我正在准备一个关于shared_ptr的工作报告。我使用了经过修改的boost shared_ptr，避免了单独的malloc(就像make_shared可以做的那样)，以及上面提到的shared_ptr_unsynchronized这样的锁策略的模板param。我正在使用来自
http://flyingfrogblog.blogspot.hk/2011/01/boosts-sharedptr-up-to-10-slower-than.html
http://flyingfrogblog.blogspot.hk/2011/01/boosts-sharedptr-up-to-10-slower-than.html
as a test, after cleaning up the unnecessary shared_ptr copies. The program uses the main thread only and the test argument is shown. The test env is a notebook running linuxmint 14. Here is the time taken in seconds:
作为测试，在清除了不必要的shared_ptr副本之后。程序只使用主线程，并显示测试参数。测试env是一个运行linuxmint 14的笔记本。这是用秒来表示的时间:
test run setup boost(1.49) std with make_shared modified boost mt-unsafe(11) 11.9 9/11.5(-pthread on) 8.4 atomic(11) 13.6 12.4 13.0 mt-unsafe(12) 113.5 85.8/108.9(-pthread on) 81.5 atomic(12) 126.0 109.1 123.6
Only the 'std' version uses -std=cxx11, and the -pthread likely switches lock_policy in g++ __shared_ptr class.
只有“std”版本使用-std=cxx11，并且-pthread可能在g++ __shared_ptr类中切换lock_policy。
From these numbers, I see the impact of atomic instructions on code optimization. The test case does not use any C++ containers, but vector<shared_ptr<some_small_POD>> is likely to suffer if the object doesn't need the thread protection. Boost suffers less probably because the additional malloc is limiting the amount of inlining and code optimizaton.
从这些数字中，我看到了原子指令对代码优化的影响。测试用例不使用任何c++容器，但是如果对象不需要线程保护，那么向量
I have yet to find a machine with enough cores to stress test the scalability of atomic instructions, but using std::shared_ptr only when necessary is probably better.
我还没有找到一台拥有足够多内核的机器来强调测试原子指令的可伸缩性，但只有在必要时才使用std::shared_ptr可能更好。
#1
83
1. I'm wondering if there is a non-atomic version of std::shared_ptr available
1。我想知道是否有一个非原子版本的std::shared_ptr。
Not provided by the standard. There may well be one provided by a "3rd party" library. Indeed, prior to C++11, and prior to Boost, it seemed like everyone wrote their own reference counted smart pointer (including myself).
本标准未规定。可能会有一个由“第三方”图书馆提供。实际上，在c++ 11之前，在Boost之前，似乎每个人都编写了自己的引用计数智能指针(包括我自己)。
2. My second question is why wasn't a non-atomic version of std::shared_ptr provided in C++11?
2。我的第二个问题是，为什么非原子版本的std::shared_ptr在c++ 11中提供?
This question was discussed at the Rapperswil meeting in 2010. The subject was introduced by a National Body Comment #20 by Switzerland. There were strong arguments on both sides of the debate, including those you provide in your question. However, at the end of the discussion, the vote was overwhelmingly (but not unanimous) against adding an unsynchronized (non-atomic) version of shared_ptr.
这个问题在2010年的Rapperswil会议上被讨论过。瑞士国家机构第20号评论介绍了这个话题。辩论双方都有有力的论点，包括你在问题中提出的论点。然而，在讨论结束时，压倒性地(但并非一致地)投票反对添加shared_ptr的非同步(非原子)版本。
Arguments against included:
反对包括:
-
Code written with the unsynchronized shared_ptr may end up being used in threaded code down the road, ending up causing difficult to debug problems with no warning.
使用非同步shared_ptr编写的代码最终可能会被用于线程代码，最终导致在没有警告的情况下难以调试问题。
-
Having one "universal" shared_ptr that is the "one way" to traffic in reference counting has benefits: From the original proposal:
拥有一个“通用”shared_ptr，即引用计数的“单向”流量，有好处:
Has the same object type regardless of features used, greatly facilitating interoperability between libraries, including third-party libraries.
无论使用什么特性，都具有相同的对象类型，这极大地促进了库之间的互操作性，包括第三方库。
-
The cost of the atomics, while not zero, is not overwhelming. The cost is mitigated by the use of move construction and move assignment which do not need to use atomic operations. Such operations are commonly used in
vector<shared_ptr<T>>erase and insert.原子的成本虽然不是零，但也不是压倒性的。使用不需要使用原子操作的移动构造和移动分配可以降低成本。这种操作通常用于向量
>擦除和插入。 -
Nothing prohibits people from writing their own non-atomic reference-counted smart pointer if that's really what they want to do.
没有什么能阻止人们编写他们自己的非原子引用计数智能指针，如果这是他们真正想做的。
The final word from the LWG in Rapperswil that day was:
当天，来自Rapperswil的LWG的最后一句话是:
Reject CH 20. No consensus to make a change at this time.
拒绝CH 20。目前还没有做出改变的共识。
#2
41
Howard's answered the question well already, and Nicol made some good points about the benefits of having a single standard shared pointer type, rather than lots of incompatible ones.
Howard已经很好地回答了这个问题，Nicol提出了一些关于拥有一个标准共享指针类型的好处，而不是许多不兼容的指针类型。
While I completely agree with the committee's decision, I do think there is some benefit to using an unsynchronized shared_ptr-like type in special cases, so I've investigated the topic a few times.
虽然我完全同意委员会的决定，但我确实认为在特殊情况下使用非同步shared_ptrlike类型有一些好处，因此我对这个主题进行了几次调查。
If I'm not using multiple threads, or if I am using multiple threads but am not sharing pointer ownership across threads, an atomic smart pointer is overkill.
如果我没有使用多个线程，或者我正在使用多个线程，但是没有跨线程共享指针所有权，那么原子智能指针就会被过度使用。
With GCC when your program doesn't use multiple threads shared_ptr doesn't use atomic ops for the refcount. This is done by updating the reference counts via wrapper functions that detect whether the program is multithreaded (on GNU/Linux this is done simply by detecting whether the program links to libpthread.so) and dispatch to atomic or non-atomic operations accordingly.
使用GCC时，当程序不使用多线程shared_ptr时，refcount就不使用原子操作。这是通过通过包装器函数更新引用计数来实现的，它可以检测程序是多线程的(在GNU/Linux上，这仅仅是通过检测程序链接到libpthreadso)，并相应地发送到原子或非原子操作。
I realised many years ago that because GCC's shared_ptr<T> is implemented in terms of a __shared_ptr<T, _LockPolicy> base class, it's possible to use the base class with the single-threaded locking policy even in multithreaded code, by explicitly using __shared_ptr<T, __gnu_cxx::_S_single>. Unfortunately because that wasn't an intended use case it didn't quite work optimally before GCC 4.9, and some operations still used the wrapper functions and so dispatched to atomic operations even though you've explicitly requested the _S_single policy. See point (2) at http://gcc.gnu.org/ml/libstdc++/2007-10/msg00180.html for more details and a patch to GCC to allow the non-atomic implementation to be used even in multithreaded apps. I sat on that patch for years but I finally committed it for GCC 4.9, which allows you to use an alias template like this to define a shared pointer type that is not thread-safe, but is slightly faster:
我多年前就意识到，因为GCC的shared_ptr
template<typename T>
using shared_ptr_unsynchronized = std::__shared_ptr<T, __gnu_cxx::_S_single>;
This type would not be interoperable with std::shared_ptr<T> and would only be safe to use when it is guaranteed that the shared_ptr_unsynchronized objects would never be shared between threads without additional user-provided synchronization.
这种类型不能与std: shared_ptr
This is of course completely non-portable, but sometimes that's OK. With the right preprocessor hacks your code would still work fine with other implementations if shared_ptr_unsynchronized<T> is an alias for shared_ptr<T>, it would just be a little faster with GCC.
这当然是完全不可移植的，但有时也可以。如果使用正确的预处理器hacks，如果shared_ptr_unsynchronized
If you're using a GCC before 4.9 you could use that by adding the _Sp_counted_base<_S_single> explicit specializations to your own code (and ensuring noone ever instantiates __shared_ptr<T, _S_single> without including the specializations, to avoid ODR violations.) Adding such specializations of std types is technically undefined, but would work in practice, because in this case there's no difference between me adding the specializations to GCC or you adding them to your own code.
如果您在4.9之前使用GCC，您可以将_Sp_counted_base<_S_single>显式专门化添加到您自己的代码中(并确保没有人实例化__shared_ptr
#3
20
My second question is why wasn't an atomic version of std::shared_ptr provided in C++11? (assuming there is a why).
我的第二个问题是，为什么std的原子版本不是:shared_ptr在c++ 11中提供的?(假设有原因的话)。
One could just as easily ask why there isn't an intrusive pointer, or any number of other possible variations of shared pointers one could have.
人们也可以很容易地问为什么没有插入指针，或者有任何其他可能的共享指针变体。
The design of shared_ptr, handed down from Boost, has been to create a minimum standard lingua-franca of smart pointers. That, generally speaking, you can just pull this down off the wall and use it. It's something that would be used generally, across a wide variety of applications. You can put it in an interface, and odds are good people will be willing to use it.
shared_ptr是由Boost提供的，其设计是创建一个智能指针的最小标准通用语言。一般来说，你可以把它从墙上拉下来用。它将被广泛应用于各种各样的应用中。你可以把它放到一个界面中，很有可能会有好的人愿意使用它。
Threading is only going to get more prevalent in the future. Indeed, as time passes, threading will generally be one of the primary means to achieve performance. Requiring the basic smart pointer to do the bare minimum needed to support threading facilitates this reality.
线程化只会在将来变得更加普遍。的确，随着时间的推移，线程化通常将是实现性能的主要手段之一。需要基本的智能指针来完成支持线程所需的最低限度，这有助于实现这一现实。
Dumping a half-dozen smart pointers with minor variations between them into the standard, or even worse a policy-based smart pointer, would have been terrible. Everyone would pick the pointer they like best and forswear all others. Nobody would be able to communicate with anyone else. It'd be like the current situations with C++ strings, where everyone has their own type. Only far worse, because interoperation with strings is a lot easier than interoperation between smart pointer classes.
将六个智能指针(它们之间的差异很小)转储到标准中，甚至是基于策略的智能指针，都是很糟糕的。每个人都会选择他们最喜欢的指针，并放弃所有其他的。没人能和别人交流。就像当前的c++字符串，每个人都有自己的类型。更糟糕的是，因为使用字符串进行互操作比在智能指针类之间进行互操作要容易得多。
Boost, and by extension the committee, picked a specific smart pointer to use. It provided a good balance of features and was widely and commonly used in practice.
Boost和委员会进一步选择了一个特定的智能指针来使用。它提供了良好的功能平衡，并在实践中广泛和普遍使用。
std::vector has some inefficiencies compared to naked arrays in some corner cases too. It has some limitations; some uses really want to have a hard limit on the size of a vector, without using a throwing allocator. However, the committee didn't design vector to be everything for everyone. It was designed to be a good default for most applications. Those for whom it can't work can just write an alternative that suites their needs.
在某些情况下，向量与裸数组相比也有一些低效率。它有一些局限性;有些应用真的想要对向量的大小有一个硬限制，而不需要使用抛出分配器。然而，委员会并没有把向量设计成每个人的一切。它被设计成大多数应用程序的良好默认值。对于那些无法工作的人来说，可以编写一个满足他们需求的替代方案。
Just as you can for a smart pointer if shared_ptr's atomicity is a burden. Then again, one might also consider not copying them around so much.
就像对于智能指针一样，如果shared_ptr的原子性是一个负担。同样，你也可以考虑不经常复制它们。
#4
4
I am preparing a talk on shared_ptr at work. I have been using a modified boost shared_ptr with avoid separate malloc (like what make_shared can do) and a template param for lock policy like shared_ptr_unsynchronized mentioned above. I am using the program from
我正在准备一个关于shared_ptr的工作报告。我使用了经过修改的boost shared_ptr，避免了单独的malloc(就像make_shared可以做的那样)，以及上面提到的shared_ptr_unsynchronized这样的锁策略的模板param。我正在使用来自
http://flyingfrogblog.blogspot.hk/2011/01/boosts-sharedptr-up-to-10-slower-than.html
http://flyingfrogblog.blogspot.hk/2011/01/boosts-sharedptr-up-to-10-slower-than.html
as a test, after cleaning up the unnecessary shared_ptr copies. The program uses the main thread only and the test argument is shown. The test env is a notebook running linuxmint 14. Here is the time taken in seconds:
作为测试，在清除了不必要的shared_ptr副本之后。程序只使用主线程，并显示测试参数。测试env是一个运行linuxmint 14的笔记本。这是用秒来表示的时间:
test run setup boost(1.49) std with make_shared modified boost mt-unsafe(11) 11.9 9/11.5(-pthread on) 8.4 atomic(11) 13.6 12.4 13.0 mt-unsafe(12) 113.5 85.8/108.9(-pthread on) 81.5 atomic(12) 126.0 109.1 123.6
Only the 'std' version uses -std=cxx11, and the -pthread likely switches lock_policy in g++ __shared_ptr class.
只有“std”版本使用-std=cxx11，并且-pthread可能在g++ __shared_ptr类中切换lock_policy。
From these numbers, I see the impact of atomic instructions on code optimization. The test case does not use any C++ containers, but vector<shared_ptr<some_small_POD>> is likely to suffer if the object doesn't need the thread protection. Boost suffers less probably because the additional malloc is limiting the amount of inlining and code optimizaton.
从这些数字中，我看到了原子指令对代码优化的影响。测试用例不使用任何c++容器，但是如果对象不需要线程保护，那么向量
I have yet to find a machine with enough cores to stress test the scalability of atomic instructions, but using std::shared_ptr only when necessary is probably better.
我还没有找到一台拥有足够多内核的机器来强调测试原子指令的可伸缩性，但只有在必要时才使用std::shared_ptr可能更好。