OpenMP task指令必须在parallel区域内使用，否则仅注册任务不触发并行；需配合single/master避免重复创建任务，并显式taskwait等待子任务完成，且要注意变量作用域、调度开销与适用场景。
OpenMP task 指令必须配合 parallel 区域才能生效
单独写 #pragma omp task 不会触发并行，它只是把任务注册进当前线程的任务队列——但如果没有并行区域，整个程序还是单线程跑，任务也不会被调度出去。常见错误是只加 task 却漏掉 parallel，结果性能毫无提升，还误以为 OpenMP 有问题。
正确做法是：用 #pragma omp parallel 启动线程组，再在其中用 #pragma omp single 或 #pragma omp master 触发任务生成（避免每个线程都重复创建相同任务）。例如：
#pragma omp parallel
#pragma omp single
{
#pragma omp task
f1();
#pragma omp task
f2();
#pragma omp taskwait;
}
-
single确保任务只由一个线程创建，避免冗余 - 不加
single而直接放在parallel块里，会导致所有线程都各自创建一遍f1和f2，逻辑错乱 -
taskwait必须显式写，否则主线程不会等任务完成就退出了
taskwait 不等于 barrier，它只等待本作用域内生成的任务
#pragma omp taskwait 只阻塞当前线程，等待「该线程（或其子任务）所生成的、尚未完成的 direct child tasks」——不是所有线程的所有任务，也不是全局任务池。容易踩的坑是误以为它能同步跨线程任务，结果出现数据竞争或未定义行为。
典型场景：递归分治（如快速排序切分后并行处理左右子数组），父任务生成两个子 task，然后 taskwait 等它们结束。这时没问题；但如果子任务内部又生成新任务，而你没在子任务里加 taskwait，父任务的 taskwait 不会等那些“孙子任务”。
立即学习“C++免费学习笔记（深入）”；
- 嵌套任务需逐层
taskwait，或改用taskgroup+ 隐式等待 -
taskwait不释放线程，线程会空转等待；若任务耗时极长且依赖外部事件，要考虑是否更适合用taskyield - 没有对应
task的taskwait是合法的，但无实际效果
task 的默认调度和 shared/private 陷阱
OpenMP 默认按 if 子句决定是否真正并行化任务：如果 if(0)，任务就在当前线程同步执行；if(1) 才尝试异步调度。很多代码忽略这点，导致调试时看似串行、上线后行为突变。
变量作用域也极易出错：task 默认继承 enclosing context 的变量绑定方式，但局部变量在 task 中访问时，若原函数已返回，就会读到栈内存垃圾。必须显式用 firstprivate 或 shared 控制生命周期。
- 循环变量（如
i）在for中生成多个task时，必须firstprivate(i)，否则所有 task 共享同一个i地址，值不可控 -
default(none)是强烈推荐的，强迫你逐个声明每个变量的共享策略 -
task中调用的 lambda 若捕获了局部变量，同样要小心——C++11+ 的 lambda 默认按值捕获，但若捕获的是指针或引用，仍可能悬空
编译与运行时开销：task 不是万能加速器
每个 task 创建有固定开销（约几十到上百纳秒），远高于普通函数调用。当任务体太小（比如只做几次加法），并行反而更慢；OpenMP 运行时还要维护任务队列、窃取调度、同步状态，这些在轻量级计算中占比极高。
适用边界很明确：任务粒度建议 ≥ 10μs，且最好有明显计算/IO 耦合（如矩阵块运算、文件解析、网络请求回调）。调试时可用 OMP_DISPLAY_ENV=TRUE 查看实际启用的线程数和调度策略。
- Clang/GCC 需显式加
-fopenmp，且 GCC task 支持不完整 - Linux 上可通过
/proc/<pid>/status</pid>的Threads:行观察真实线程数，别只信omp_get_num_threads() - 任务太多（>10⁵）可能压垮任务队列，此时应考虑用
sections或手工分块代替细粒度task
