我有一个std::deque<std::pair<CustomObj, int>>，在启动并发块时大小不会改变。
并发块读取deque中的每个CustomObj并设置int。
我可以保证双端队列不会改变大小，因此不会重新分配，并且每个线程只会访问双端队列的内存块，而不会访问其他线程的内存块。
是否会导致并发读写的未定义行为？我应该把写作和阅读放在一个互斥区吗？
【问题讨论】：
标签： c++ multithreading c++11 openmp
令我惊讶的是，在当前标准本身中实际上有一个非常明确的部分：
(C++17, 26.2.2 容器数据竞争, 2)
- 尽管有 20.5.5.9 的规定，当同时修改同一容器中不同元素中包含的对象的内容（
vector<bool>除外）时，实现需要避免数据争用。
您也可以毫无顾虑地调用以下访问器：
- 为了避免数据竞争 (20.5.5.9)，实现应考虑以下功能 常量：
begin, end, rbegin, rend, front, back, data, find, lower_bound, upper_bound, equal_range, at并且，除了在关联或无序关联容器中，operator[]。
由于std::deque 也不例外，您可以同时调用任何这些函数来获取不同的元素并修改它们。只需确保将对容器本身的任何修改与您同时访问和修改元素的并行区域正确隔离。
例如这是错误的：
std::dequeue<...> dq;
#pragma omp master
{
...
dq.emplace(...);
}
// no implicit barrier here,
// use omp barrier or change to omp single instead of master
#pragma omp for
for (... i; ...)
dq[i].second = compute(dq[i]);
【讨论】：
std::vector<bool> 这导致我得到这个答案，因为对现有的评论太长了。
deque 在任一端插入时具有引用稳定性，因此如果可以在代码的同步部分中执行auto &ref = dq[i];，那么ref 可以是与push_back()、push_front() 等同时访问 - 不幸的是迭代器无效，因此在给定循环中，您必须事先存储每个指针或引用。
只要您可以保证deque 的大小不会改变，并且只有一个线程会写入特定元素，那么是的，这是安全的。只有当您尝试修改 deque（更改它的大小）或者当您有多个线程读取和写入 deque 内的单个元素时，您才会遇到问题。
你可以体验到的一件事叫做false sharing。这是具有多个线程正在使用的元素的单个高速缓存行的过程。由于线程写入会弄脏缓存行，因此需要重新同步整个内容，这会损害性能
【讨论】：
#pragma omp for。
std::vector 声称“写入时没有并发阅读器”。它没有说他是指容器还是容器的元素。我仍然像您一样认为，鉴于我的上下文，写入和读取不同的内存位置是安全的。另外，我的并发块中没有push_back。
deque 内的单个元素，您将是安全的。跨度>
所有标准容器的规则是：
这只是适度太强了。您可以做少量违反上述规则的事情，而不会成为标准下的竞争条件。
在标准中，这通常用容器上的const 方法来表述。读方法是const，写方法不是const。例外情况是非const 的begin() 和end() 和data()（只返回迭代器的方法）算作const。
对于迭代和元素访问，它的措辞是迭代器失效。许多操作使迭代器失效，如果迭代器在使用时以无序方式失效，则它是一种竞争条件。
作为一个例子，上面的经验法则说“不”但标准说“好的”：
您可以存储地图和对地图中值的引用。您可以在另一个线程向映射添加键值对时编辑值。
由于地图没有使迭代器失效，并且您没有触摸键，我相信没有竞争条件。
【讨论】：