为什么std::execution::par搭配std::views::iota迭代器不会启动多线程？

问题原因 #

这个现象是迭代器兼容性和并行STL实现的共同作用导致的，核心原因有3点：

1. 并行算法对迭代器的硬性要求
   C++17标准的并行STL（带std::execution策略的算法）要求传入的迭代器必须满足*遗留随机访问迭代器（LegacyRandomAccessIterator）*的所有约束。std::vector的迭代器完全符合该要求，所以TBB后端可以正常将元素范围拆分为多个子块，分配给不同线程并行执行，符合你的预期。
2. std::views::iota迭代器的兼容性问题
   你使用的GCC 11版本中，std::views::iota的迭代器仅符合C++20概念层面的random_access_iterator要求，不满足旧版遗留随机访问迭代器的核心约束：旧规范要求迭代器解引用必须返回元素的左值引用，而iota迭代器解引用返回的是临时生成的整数值（右值），不满足左值引用要求。
3. TBB后端的降级逻辑
   Intel TBB作为GCC并行STL的默认后端，当检测到传入的迭代器不符合可并行拆分的迭代器要求时，为了保证执行正确性，会直接退化为单线程串行执行所有任务，这就是iota版本仅出现单个线程的原因。

解决方案 #

• 最稳妥的方案就是你第一个版本的实现：先把iota视图转存为std::vector，再传入并行算法，兼容性最好，性能损耗可以忽略。
• 升级编译器到GCC 12及以上版本：GCC 12对范围迭代器做了大量兼容优化，部分场景下iota迭代器已经可以被TBB识别为合法的可拆分迭代器，能正常触发多线程执行。
• 手动拆分iota范围：如果不想引入vector的内存开销，也可以手动对iota的数值范围做分块，用std::async等工具自己实现并行逻辑，不过开发成本比转存vector高很多。

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