std::deque线程安全疑问：单线程持首元素引用时其他线程操作尾部可行吗？

问题回顾 #

能否让一个线程持有std::deque首元素的引用（或迭代器），同时另一个线程仅在尾部添加/删除元素（绝不触碰首元素）？已知可以用互斥锁锁定整个数据结构，但疑惑既然尾部增删不会使头部迭代器失效（假设首尾不重合），这样操作是否可行？

补充示例（MacOS clang-15下出现竞态条件导致断言失败，反向操作看似正常）：

#include <deque>
#include <thread>
#include <cassert>
#include <chrono>

int main()
{
  std::deque<int> deque;
  deque.push_back(42);
  auto thread1 = std::thread([&](){
    for (auto i = 0u; i < 1000000000; ++i)
    {
      auto& j = deque.back();
      using namespace std::chrono_literals;
      std::this_thread::sleep_for(10ms);
      assert(j == deque.back());
    }
  });
  auto thread2 = std::thread([&](){
    for (auto i = 0u; i < 1000000000; ++i)
      if (deque.size() == 1)
        deque.push_front(43);
      else
        deque.pop_front();
  });
  thread1.join();
  thread2.join();
}

核心结论 #

这种无同步的跨线程操作绝对不可行，属于C++标准定义的未定义行为，哪怕你认为尾部操作不影响头部迭代器的有效性。

原因解析 #

1. 标准容器的多线程规则限制
   C++标准明确规定：标准容器仅在两种场景下支持多线程安全访问：

   • 所有线程都只执行只读操作；
   • 仅有一个线程执行写操作，其他线程不进行任何操作。
     只要存在多线程同时操作（含一读一写），不管操作的是容器的哪个区域，都必须通过同步机制（如互斥锁）保护，否则就是数据竞争，触发未定义行为。

2. 容器内部全局状态的竞态问题
   即使尾部增删不直接修改首元素的存储，容器内部的全局状态（比如size()值、管理分段内存的指针数组）会被写操作修改。而读操作（比如获取首元素引用、调用front()）需要读取这些全局状态，跨线程无同步的读写会导致这些值被撕裂读取，出现不一致的结果。

3. 迭代器有效性≠线程安全
   迭代器或引用的有效性是单线程场景下的规则——指单线程中执行操作后，迭代器是否还能指向正确的元素。但这和多线程安全是完全不同的概念：即使迭代器本身有效，跨线程无同步的读写依然会触发数据竞争，属于未定义行为。

示例故障分析 #

你给出的示例中，线程1持有尾部元素的引用并断言，线程2修改头部元素，最终断言失败：

• 线程2的push_front()和pop_front()会修改容器的size以及内部的段指针数组；
• 线程1调用deque.back()时需要读取这些内部状态，此时线程2可能正在修改这些值，导致back()返回的元素和之前引用的j不一致，触发断言。

而反向操作（操作尾部、读头部）看似正常，这只是未定义行为的一种随机表现，并非真的安全——未定义行为可能导致程序崩溃、输出错误结果或“正常运行”，不能以此判断操作合法。

正确实现方式 #

• 使用std::mutex或std::shared_mutex保护所有对std::deque的访问，确保同一时间只有一个线程能操作容器（读写都需要加锁）；
• 如果业务场景允许，拆分数据结构，让线程操作各自独立的数据，避免共享；
• 若需要高性能线程安全队列，可使用第三方库的线程安全容器实现，或基于std::deque封装带同步机制的容器。

内容的提问来源于stack exchange，提问作者mvc