pthread_cond_signal唤醒有延时？
有n个线程：
pthread_mutex_lock(&mutex);
while(status == free){
   pthread_cond_wait(&condition,&mutex);
}
pthread_mutex_unlock(&mutex);

都在等待被唤醒。

还有一个线程收到请求后
pthread_mutex_lock(&mutex);
status = free
pthread_cond_signal(&condition);
pthread_mutex_unlock(&mutex);


同时还有一个线程：
pthread_mutex_lock(&mutex);
status = locked
pthread_mutex_unlock(&mutex);

但是我发现唤醒有延时，经常会发生signal没有唤醒wait的线程 status却被改回locked情况，请教这是什么情况
------解决方案--------------------
这样是有可能会被改成locked,因为pthread_cond_signal唤醒某个等待线程并unlock了互斥锁之后,在系统还没有来得及调度到被唤醒的等待线程前,你第三种修改状态为locked的线程先被调度了,系统的调度顺序是不可确定的.

其实你这样设计有点问题, 条件变量本来只用于等待和唤醒二种线程,现在你突然加进了第三种线程绕过了条件变量,自然会和你预期不符
------解决方案--------------------

引用:

1：free是我自己的enum
2：但是我确保第二种线程先被调用，即先signal 再修改为lock。为什么第一种线程还会抢不过第三种？

线程调度在内核里就是进程调度,很多原因决定调度哪个进程优先,所以就算衔signal也不一定第一种先运行

比如第三种线程休眠的时间更久,那他很有可能会先被调度
------解决方案--------------------

引用:

引用:1：free是我自己的enum
2：但是我确保第二种线程先被调用，即先signal 再修改为lock。为什么第一种线程还会抢不过第三种？

线程调度在内核里就是进程调度,很多原因决定调度哪个进程优先,所以就算衔signal也不一定第一种先运行

比如第三种线程休眠的时间更久,那他很有可能会先被调度

同意，线程调度跟楼主说的“先signal 再修改为lock”没关系，跟系统有关系。有些系统是让等待时间长的线程先加锁的。例如：如果第二种线程先申请pthread_mutex_lock(&mutex)，然后是第三种，然后是第一种（pthread_cond_wait激活时也有加锁的动作）。这样就会先执行按照这个顺序执行,第二种->第三种->第一种。
------解决方案--------------------
用sleep等待吧