你完全猜对了——被条件变量唤醒的线程，在重新获取互斥锁时没有任何特殊优先权，它们会和所有其他尝试获取该互斥锁的线程（不管是刚发起pthread_mutex_lock()调用的，还是从pthread_cond_wait()里刚醒过来的）一起，严格按照系统的调度策略公平竞争。

先看你提到的文档描述，这已经说得很明确了：

被解除阻塞的线程应根据调度策略（如适用）争夺互斥锁，就像每个线程都调用了pthread_mutex_lock()一样。

这句话的核心就是：唤醒后的线程在锁竞争环节和普通加锁线程完全等价，系统不会为它们开任何“绿色通道”。

再来看你给出的例子：

• 线程1的逻辑：

  while(1) {
      pthread_mutex_lock(&mutex);
      pthread_cond_wait(&cond, &mutex);
      pthread_mutex_unlock(&mutex);
  }
  

• 线程2的逻辑：

  while(1) {
      pthread_mutex_lock(&mutex);
      pthread_cond_signal(&cond);
      pthread_mutex_unlock(&mutex);
  }
  

这种场景下，完全可能出现线程2连续两次抢到锁、调用两次signal，而线程1始终卡在等待互斥锁的队列里的情况。

原因很简单：线程2解锁后，调度器完全有可能再次选中它（比如时间片还没耗尽，或者调度策略偏向它），让它立刻重新获取锁并再次发送信号。而被唤醒的线程1，此时只是加入了互斥锁的等待队列，和线程2（以及其他潜在竞争者）处于同一起跑线，没有任何优先获取锁的权利——它只能等着调度器选中自己，才能完成pthread_cond_wait()里隐含的pthread_mutex_lock()操作，进入下一轮循环。

如果想避免这种极端的“饥饿”情况，你可能需要额外做一些控制：比如调整线程的调度优先级，或者让线程2在发送信号后主动调用sched_yield()让出CPU，但这些都不属于pthread条件变量的默认行为。

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