parallel_for 的基本用法和常见错误
parallel_for 是 oneTBB 最常用的任务并行接口，它把一个迭代空间（如 std::vector 的索引范围）自动切分成多个子区间，由线程池并发执行。但很多人一上来就写 tbb::parallel_for(0, n, [](int i) { /* ... */ });，结果发现没提速甚至崩溃——根本原因是默认策略下，int 范围会被当作 size_t 处理，若 n 为负或极大值（如 INT_MAX），会触发未定义行为。
- 必须显式指定迭代器类型：推荐用
tbb::blocked_range或直接使用带类型推导的tbb::parallel_for(tbb::make_blocked_range(0U, n), ...) - lambda 捕获需谨慎：
[&]在并行中可能引发数据竞争；只读访问可用[=]，写共享变量必须加锁或改用tbb::parallel_reduce - 不要在 lambda 内抛异常：oneTBB 默认不传播异常，会导致静默终止；如需异常支持，得配合
tbb::task_group或启用TBB_USE_EXCEPTIONS=1编译宏
range 分割策略影响性能的关键点
oneTBB 不是简单按线程数均分循环次数，而是通过 tbb::blocked_range 的 grainsize 控制最小任务粒度。太小（如 grainsize=1）导致任务调度开销压倒计算收益；太大（如 grainsize=n/2）则并行度不足，无法压满 CPU。
- 默认
grainsize是 1，但实际应设为「单次迭代耗时 ≥ 1–10 μs」对应的数据量，例如遍历数组做浮点运算，可设为std::max(1024U, n / (tbb::this_task_arena::max_concurrency() * 4)) - 若迭代体有明显冷热分离（如前 10% 数据需要预热 cache），可用自定义
split或改用tbb::parallel_for_each配合std::deque手动分块 - 注意
tbb::blocked_range的模板参数顺序：tbb::blocked_range和tbb::blocked_range行为不同，后者可能因符号扩展出错
与 std::for_each 和 OpenMP 的关键差异
对比 std::for_each（串行）、OpenMP 的 #pragma omp parallel for，tbb::parallel_for 的核心优势在于任务窃取（work-stealing）调度器，能动态平衡负载。但它不保证执行顺序，也不隐含内存屏障。
- OpenMP 的
schedule(dynamic)类似，但 oneTBB 的窃取发生在任务级，粒度更细、响应更快；而 OpenMP 多数实现是 chunk 级静态划分 -
std::for_each+ 执行策略（如std::execution::par_unseq）底层可能调用 oneTBB，但标准未规定，且 GCC libstdc++ 当前仍用 pthread 封装，不可移植 - oneTBB 不自动插入内存屏障：若迭代体修改全局指针或
std::atomic外的变量，需手动加std::atomic_thread_fence或用tbb::concurrent_vector替代裸容器
一个安全可用的 parallel_for 示例
以下代码处理 std::vector 的就地平方，兼顾类型安全、粒度控制和异常安全：
立即学习“C++免费学习笔记（深入）”；
#include#include #include void safe_square(std::vector
& v) { if (v.empty()) return; tbb::parallel_for( tbb::blocked_range (0, v.size(), 4096), [&](const tbb::blocked_range & r) { for (size_t i = r.begin(); i != r.end(); ++i) { v[i] = v[i] * v[i]; } } ); }
这里 4096 是 grainsize，适配典型 L1 cache line 大小；size_t 避免符号问题；range 构造函数第三个参数直接控制分割粒度，比在 lambda 里判断更高效。真正难的是评估 grainsize —— 它依赖硬件缓存、数据局部性、以及迭代体是否含分支预测失败，没法一劳永逸。
