pthread_cond_signal唤醒有延时？该如何处理
pthread_cond_signal唤醒有延时？有n个线程：pthread_mutex_lock(&mutex)while(status free){pthread_co
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情况，请教这是什么情况
[最优解释]
线程调度在内核里就是进程调度,很多原因决定调度哪个进程优先,所以就算衔signal也不一定第一种先运行
比如第三种线程休眠的时间更久,那他很有可能会先被调度
[其他解释]这样是有可能会被改成locked,因为pthread_cond_signal唤醒某个等待线程并unlock了互斥锁之后,在系统还没有来得及调度到被唤醒的等待线程前,你第三种修改状态为locked的线程先被调度了,系统的调度顺序是不可确定的.
其实你这样设计有点问题, 条件变量本来只用于等待和唤醒二种线程,现在你突然加进了第三种线程绕过了条件变量,自然会和你预期不符
[其他解释]同意，线程调度跟楼主说的“先signal 再修改为lock”没关系，跟系统有关系。有些系统是让等待时间长的线程先加锁的。例如：如果第二种线程先申请pthread_mutex_lock(&mutex)，然后是第三种，然后是第一种（pthread_cond_wait激活时也有加锁的动作）。这样就会先执行按照这个顺序执行,第二种->第三种->第一种。
[其他解释]用sleep等待吧
[其他解释]free是标准库函数啊
[其他解释]status被修改为locked与wait唤醒没有什么关系啊？只有第二个线程发送信号与第一个线程等待信号有关系啊。
[其他解释]经常会发生signal没有唤醒wait的线程 status却被改回locked情况
这是修改status = locked的线程先得到了mutex
[其他解释]1：free是我自己的enum
2：但是我确保第二种线程先被调用，即先signal 再修改为lock。为什么第一种线程还会抢不过第三种？
