为何子线程的mutex无法在主线程循环结束前获取锁？

我来帮你分析下问题根源，以及几种不需要加延迟的优雅解决办法：

问题本质 #

你遇到的情况是典型的忙等循环抢占CPU资源导致的：主线程在while循环里几乎不间断地执行pthread_mutex_lock/unlock操作——解锁后立刻又尝试加锁。由于线程调度的特性，主线程大概率会持续占有CPU时间片，子线程虽然已经就绪，但根本没机会被调度执行；就算子线程尝试自旋获取锁，主线程也会马上重新拿到锁，子线程自旋失败后进入休眠，彻底错过了调度窗口。添加10ms延迟本质是强制主线程放弃CPU，给子线程留出运行机会，但这不是规范的同步方案。

解决方案 #

1. 使用条件变量（推荐，最标准的同步方式）

条件变量就是为解决忙等问题设计的，它能让线程在不满足执行条件时进入休眠，直到被其他线程唤醒，完全避免无意义的CPU占用。结合你的场景，调整逻辑如下：

// 全局/共享同步变量
pthread_mutex_t Mutex;
pthread_cond_t Cond;

// 主线程逻辑
pthread_create(&thread1, NULL, thread_func, NULL);
pthread_mutex_lock(&Mutex);
// 条件不满足时，释放锁并进入休眠，被唤醒后自动重新获取锁
while(p.size() <= r.size()){
    pthread_cond_wait(&Cond, &Mutex);
}
// 执行计算并减小p.size()的逻辑
pthread_mutex_unlock(&Mutex);

// 子线程逻辑
sleep(0.5); // 等待500ms
pthread_mutex_lock(&Mutex);
// 执行你的计算操作（比如修改r或p的内容）
// 如果主线程的执行条件被满足，唤醒等待的主线程
pthread_cond_signal(&Cond);
pthread_mutex_unlock(&Mutex);

这样主线程不会无意义地循环加解锁，只有当条件满足时才会被唤醒执行，子线程能顺利获取锁完成操作。

2. 主动让出CPU时间片

如果不想大幅修改现有逻辑，可以在主线程解锁后调用sched_yield()函数，主动告诉调度器：“我现在可以让出CPU，让其他线程运行”。这样子线程有更大概率被调度，从而获取到锁。

修改后的主线程代码：

while(p.size() > r.size()){
 pthread_mutex_lock(&Mutex);
 // 计算并减小p.size()
 pthread_mutex_unlock(&Mutex);
 sched_yield(); // 主动让出CPU，给其他线程调度机会
}

这个方法比固定延迟更灵活，它不是强制等待固定时间，而是让调度器根据实际情况决定线程切换时机，效率更高。

3. 调整Mutex类型（不推荐，仅作补充）

默认的pthread mutex是自适应锁：当锁被持有时间短时会自旋，时间长则会休眠。你可以尝试将mutex设置为强制自旋类型（但注意自旋锁在锁持有时间长时会浪费CPU），不过这种方法依赖系统实现，可移植性差，不如前两种方法可靠。

示例初始化代码：

pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
// 设置为自旋锁（部分系统如Linux支持该非标准类型）
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_SPIN_NP);
pthread_mutex_init(&Mutex, &attr);

总结 #

最推荐的是条件变量方案，它从根源上解决了忙等问题，是多线程同步的标准做法；如果只是临时调整代码，sched_yield()是简单有效的过渡办法。

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