为何std::mutex无法与std::execution::par_unseq配合使用？

核心原因1：向量化优化触发非递归互斥量的未定义行为 #

std::execution::par_unseq允许编译器对循环做向量化优化——把多个循环迭代打包到同一个线程的SIMD指令中执行。这意味着同一个线程会连续执行多个lambda实例，每个实例都会调用std::mutex::lock()。

而std::mutex是非递归互斥量，C++标准明确规定：同一线程在未解锁互斥量的情况下再次调用lock()属于未定义行为，常见表现为死锁（线程自我阻塞）或程序崩溃。你给出的示例代码中，两个数组元素的迭代很可能被向量化到同一线程执行，第一个lock_guard还未销毁（未解锁），第二个lock_guard又尝试锁定同一个互斥量，直接触发未定义行为。

核心原因2：违背par_unseq的执行模型假设 #

par_unseq要求循环的每个迭代操作必须满足：

• 无副作用（或副作用不影响其他迭代）
• 可重入
• 不依赖迭代的执行顺序

std::mutex的lock()/unlock()是强副作用操作，它强制了迭代之间的执行顺序（必须等前一个迭代解锁后，下一个才能锁定），完全破坏了par_unseq允许的自由重排、并行/向量化执行的基础。即使没触发同一线程重复锁定的问题，这种用法也会让par_unseq的优化完全失效，同时导致程序行为不可预测——编译器可能任意重排迭代顺序，而mutex的存在会引发数据竞争或逻辑错误。

总结来说，这种用法非法的本质是：std::mutex的特性和par_unseq的执行模型完全冲突，前者强制顺序性和排他性，后者要求无依赖、可并行/向量化，两者无法兼容。

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