多线程热传递模拟程序并发同步问题排查求助

看起来你已经摸到问题的核心了——单线程跑结果完全正确，一上多线程就出问题，这百分百指向同步逻辑的漏洞，而非计算本身。我帮你梳理下代码里的几个可疑点，你可以逐一排查：

1. 信号量操作的明显笔误 #

看你主线程循环末尾的这段代码：

// 5. Unblock the threads to continue
for (uint64_t i = 0; i < shared_data->thread_count; ++i) {
    sem_post(&shared_data->thread_count2);
}

thread_count2 是个整数变量吧？但 sem_post 要求传入 sem_t* 类型的信号量指针！这里明显是变量名写错了，应该是 sem_post(&shared_data->barrier2) 才对。

如果实际代码里真的写了 thread_count2，这会导致未定义行为：强转整数为指针，操作的是随机内存地址。单线程时可能碰巧内存布局“凑对”让程序跑对，但多线程下绝对会破坏同步逻辑，导致线程乱序执行、计算结果混乱。

2. 屏障(Barrier)实现的潜在问题 #

你的线程同步用了手动实现的屏障，我再抠下细节：

• 线程做完计算后，加锁更新 sem_count，最后一个线程触发 sem_post(&barrier1) 唤醒主线程——这部分逻辑是对的，但要确认 barrier1 的初始值是0。
• 主线程唤醒后，需要让所有线程继续下一轮计算，所以要对 barrier2 执行 thread_count 次 sem_post，每个线程对应一次 sem_wait(&barrier2)——这部分逻辑没问题，但要确认 barrier2 的初始值也是0。

如果信号量初始化错了（比如初始值设为 thread_count），线程会跳过等待直接执行，导致多线程在矩阵未准备好的情况下就开始计算，结果自然出错。

3. 热传导计算的双缓冲问题（最可能的核心漏洞） #

热传导的并行计算有个关键前提：所有线程必须基于上一轮的全局矩阵状态完成计算，不能在计算过程中修改原矩阵。

如果你的 heatTransfer 函数是**原地(in-place)**修改矩阵（直接在原数组上更新温度值），那多线程会出现严重的数据竞争：比如线程A刚修改了第i行的值，线程B计算第i+1行时，就会用这个“新鲜”的错误值（串行版本用的是上一轮的旧值），导致结果偏差。

单线程时按顺序计算，不会有这个问题；但多线程并行计算时，原地修改的逻辑本身就不线程安全——哪怕你加了锁也没用，因为锁只能保证互斥，但无法保证计算依赖的是上一轮的全局状态。

正确的做法应该是用双缓冲：

• 维护两个矩阵：current_matrix（只读，上一轮的结果）和 next_matrix（只写，当前轮的计算结果）
• 每个线程负责计算 next_matrix 的指定行，完全基于 current_matrix 的数据，不会有任何竞争
• 所有线程计算完成后，主线程再交换两个矩阵的指针，进入下一轮循环

4. 边界处理的同步问题 #

你的主线程在循环里调用了 copy_borders(shared_data)，这个函数如果是处理全局固定边界（比如恒温的上下左右边），那在所有线程计算完成后执行是对的；但如果是处理线程之间的行边界，那要确保：

• 线程计算时用的是上一轮的边界值
• 边界值不会被其他线程在计算过程中修改（双缓冲天然解决这个问题）

排查建议 #

1. 先把主线程里的 thread_count2 改成 barrier2，确认所有信号量的初始化值（barrier1、barrier2 初始为0，sem_count 初始为0，mutex 正确初始化）
2. 检查 heatTransfer 的实现：是不是原地修改矩阵？如果是，立刻改成双缓冲模式
3. 多线程跑的时候，打印几轮的中间矩阵，对比单线程的结果，看哪一轮开始出现偏差，定位是同步提前还是计算逻辑的问题

内容来源于stack exchange