OpenMP并行for循环中printf输出异常及非零退出码问题

代码与异常现象 #

使用CLion搭配WSL运行以下C++代码：

#include <cstdio>
#include <omp.h>

using namespace std;

int main() {
    int chunk = 6;
    omp_set_num_threads(4);

#pragma omp parallel default(none) firstprivate(chunk)
    {
        int thread_id = omp_get_thread_num();
#pragma omp for schedule(static, chunk)
        for (int i = 0; i < 24; ++i) {
            printf("Thread %d is processing iteration %d\n", thread_id, i);

        }

    }
    return 0;
}

运行后出现三个异常：

1. 线程2的输出数据不完整
2. 线程3的部分输出数据重复
3. 程序退出码为020（八进制，对应十进制16）

1. 线程2输出不完整的原因 #

printf是线程安全但非原子操作，它的执行分为解析格式字符串、生成输出内容、写入标准输出缓冲区多个步骤。当多个线程同时调用printf时，操作系统的线程调度可能打断这些步骤，导致不同线程的输出内容交错写入。比如线程2的输出还没写完（例如只输出了Thread 2 is），其他线程的printf就开始写入，最终线程2的完整输出被拆分、穿插在其他线程的输出中，看起来像是“不完整”。

2. 线程3输出重复的原因 #

同样源于多线程无同步写入标准输出的问题：标准输出默认是行缓冲模式，但多线程环境下，缓冲区的刷新逻辑会被打乱。多个线程同时向缓冲区写入时，可能出现缓冲区内容被重复提交到终端的情况；或者某个线程的输出内容在缓冲区中被意外覆盖、重复拷贝，反映到终端上就是部分输出重复。另外，CLion的WSL终端在处理多线程并发输出时，也可能存在显示层面的异常，加重这种重复现象。

3. 非零退出码020的原因 #

020是八进制表示，转换为十进制是16，对应Linux信号SIGUSR1。出现这个退出码通常有两种可能：

• 编译时未正确启用OpenMP支持：如果编译命令没有添加-fopenmp参数，OpenMP运行时库不会被链接，程序中omp_set_num_threads、#pragma omp等指令无法正常工作，会触发运行时异常，导致进程被信号终止。
• WSL环境进程调度异常：CLion在WSL中运行程序时，可能因终端IO的并发冲突，导致进程被意外发送SIGUSR1信号，进而以非零码退出。

解决建议 #

1. 编译时添加OpenMP选项：在CLion的CMake配置中，添加以下代码确保OpenMP库被正确链接：

target_compile_options(your_target_name PRIVATE -fopenmp)
target_link_options(your_target_name PRIVATE -fopenmp)

2. 同步多线程输出：在printf外层添加OpenMP临界区，确保每个线程的输出操作原子执行：

#pragma omp critical
{
    printf("Thread %d is processing iteration %d\n", thread_id, i);
}

3. 手动刷新缓冲区：在printf后添加fflush(stdout);，强制刷新输出缓冲区，减少输出交错概率。

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