我有多个线程同时在 std::vector 的共享对象上调用 push_back().std::vector 线程安全吗?还是我需要自己实现该机制以使其线程安全?
我想避免做额外的锁定和释放"工作，因为我是图书馆用户而不是图书馆设计师.我希望为 vector 寻找现有的线程安全解决方案.boost::vector 怎么样，它是从 boost 1.48.0 开始新引入的.线程安全吗?
I have multiple threads simultaneously calling push_back() on a shared object of std::vector. Is std::vector thread safe? Or do I need to implement the mechanism myself to make it thread safe?
I want to avoid doing extra "locking and freeing" work because I'm a library user rather than a library designer. I hope to look for existing thread-safe solutions for vector. How about boost::vector, which was newly introduced from boost 1.48.0 onward. Is it thread safe?
C++ 标准为标准 C++ 库中的所有类做出了一定的线程保证.这些保证可能不是您期望的那样，但是对于所有标准 C++ 库类，都做出了某些线程安全保证.但是，请务必阅读所做的保证，因为标准 C++ 容器的线程保证通常与您希望的不一致.对于一些不同的，通常更强的类，做出了保证，下面的答案特别适用于容器.容器本质上具有以下线程安全保证:
The C++ standard makes certain threading guarantees for all the classes in the standard C++ library. These guarantees may not be what you'd expect them to be but for all standard C++ library classes certain thread safety guarantees are made. Make sure you read the guarantees made, though, as the threading guarantees of standard C++ containers don't usually align with what you would want them to be. For some classes different, usually stronger, guarantees are made and the answer below specifically applies to the containers. The containers essentially have the following thread-safety guarantees:
这些通常不是人们想要的线程安全保证，但考虑到标准容器的接口是非常合理的:它们旨在在没有多个访问线程的情况下有效使用.为他们的方法添加任何类型的锁定都会干扰这一点.除此之外，容器的接口对于任何形式的内部锁定都没有真正的用处:通常使用多种方法并且访问取决于先前访问的结果.例如，在检查容器不是 empty() 之后，可能会访问一个元素.但是，使用内部锁定时，不能保证对象在实际访问时仍在容器中.
These are typically not what people would want as thread-safety guarantees but are very reasonable given the interface of the standard containers: they are intended to be used efficiently in the absence of multiple accessing threads. Adding any sort of locking for their methods would interfere with this. Beyond this, the interface of the containers isn't really useful for any form of internal locking: generally multiple methods are used and the accesses depend on the outcome of previous accesses. For example, after having checked that a container isn't empty() an element might be accessed. However, with internal locking there is no guarantee that the object is still in the container when it is actually accessed.
为了满足提供上述保证的要求，您可能必须对并发访问的容器使用某种形式的外部锁定.我不了解 boost 容器，但如果它们的接口类似于标准容器的接口，我会怀疑它们具有完全相同的保证.
To meet the requirements which give the above guarantees you will probably have to use some form of external locking for concurrently accessed containers. I don't know about the boost containers but if they have an interface similar to that of the standard containers I would suspect that they have exactly the same guarantees.
保证和要求在 17.6.4.10 [res.on.objects] 第 1 段中给出:
The guarantees and requirements are given in 17.6.4.10 [res.on.objects] paragraph 1:
如果从不同线程调用标准库函数可能会导致数据竞争，则程序的行为是未定义的.在 17.6.5.9 中规定了可能发生这种情况的条件.[注意:修改在线程之间共享的标准库类型的对象会带来未定义行为的风险，除非该类型的对象明确指定为可共享而没有数据竞争或用户提供锁定机制.—尾注]
The behavior of a program is undefined if calls to standard library functions from different threads may introduce a data race. The conditions under which this may occur are specified in 17.6.5.9. [ Note: Modifying an object of a standard library type that is shared between threads risks undefined behavior unless objects of that type are explicitly specified as being sharable without data races or the user supplies a locking mechanism. —endnote]
... 和 17.6.5.9 [res.on.data.races].本节主要详细介绍 not 中更非正式的描述.
... and 17.6.5.9 [res.on.data.races]. This section essentially details the more informal description in the not.
这篇关于std::vector 或 boost::vector 线程安全吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！