日期:2014-05-16  浏览次数:20859 次

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等待吧