问一个关于条件变量的问题

[DoDoMouse]

对于条件变量的signal一般有这种写法：

pthread_mutex_lock(&mutex);
/**operation/
pthread_cond_signal(&cond)
pthread_mutex_unlock(&mutex)

如果这个互斥量被signal这边的函数先抢到了，那wait那边的函数岂不是收不到信号了？
怎么保证wait那边先抢到互斥量？

[赵4老师]

《Windows核心编程》

[pengzhixi]

使用了pthread_cond_signle接着不是pthread_mutex_unlock(&mutex)这里不是会释放互斥量么。被唤醒的wait线程就会获取这个互斥量。怎么说wait抢不到互斥量呢

[DoDoMouse]

引用 1 楼 zhao4zhong1 的回复:

《Windows核心编程》

对不起 我说的是linux

[DoDoMouse]

引用 2 楼 pengzhixi 的回复:

使用了pthread_cond_signle接着不是pthread_mutex_unlock(&mutex)这里不是会释放互斥量么。被唤醒的wait线程就会获取这个互斥量。怎么说wait抢不到互斥量呢

wait抢到的时候，已经signal过了，信号不就丢失了吗

[pengzhixi]

第一 你的pthread_cond_wait不是通过放到信号处理函数里面来实现这个功能的。这里所说的pthread_cond_signle发出的信号，你更多的应该看成是操作系统发出的一个通知，通知因为等待条件变量而陷入阻塞的进程。这里不是传统的信号处理。估计你的问题是如果pthread_cond_signle发出了通知，但是还没释放锁，这个时候wait得不到锁从而再次陷入阻塞，直到pthread_cond_signle线程释放锁之后才会wait成功。所以一般的建议是先释放锁 然后pthread_cond_signle。这样效率会比较高。

[DoDoMouse]

引用 5 楼 pengzhixi 的回复:

第一 你的pthread_cond_wait不是通过放到信号处理函数里面来实现这个功能的。这里所说的pthread_cond_signle发出的信号，你更多的应该看成是操作系统发出的一个通知，通知因为等待条件变量而陷入阻塞的进程。这里不是传统的信号处理。估计你的问题是如果pthread_cond_signle发出了通知，但是还没释放锁，这个时候wait得不到锁从而再次陷入阻塞，直到pthread_cond_signle线程释放锁之后才会wait成功。所以一般的建议是先释放锁 然后pthread_cond_signle。这样效率会比较高。

感谢回复。 如果被pthead_cond_signal那一边的代码先得到mutex，那就会存在这个信号丢失的问题啊。哪怕是先释放锁，然后再signal，这里面会有一个时间差，signal完毕的时候，如果wait那边的代码还没有进入状态，仍旧会得不到这个signal。除非这个signal在系统级别会对它进行处理，进行缓存。

[pengzhixi]

引用 6 楼 u011761982 的回复:

[quote=引用 5 楼 pengzhixi 的回复:] 第一 你的pthread_cond_wait不是通过放到信号处理函数里面来实现这个功能的。这里所说的pthread_cond_signle发出的信号，你更多的应该看成是操作系统发出的一个通知，通知因为等待条件变量而陷入阻塞的进程。这里不是传统的信号处理。估计你的问题是如果pthread_cond_signle发出了通知，但是还没释放锁，这个时候wait得不到锁从而再次陷入阻塞，直到pthread_cond_signle线程释放锁之后才会wait成功。所以一般的建议是先释放锁 然后pthread_cond_signle。这样效率会比较高。

感谢回复。 如果被pthead_cond_signal那一边的代码先得到mutex，那就会存在这个信号丢失的问题啊。哪怕是先释放锁，然后再signal，这里面会有一个时间差，signal完毕的时候，如果wait那边的代码还没有进入状态，仍旧会得不到这个signal。除非这个signal在系统级别会对它进行处理，进行缓存。[/quote]看来你还是没理解啊，pthead_cond_signal不是说产生常规的信号啊，pthread_cond_wait只是把当前线程阻塞，然后在阻塞前释放mutex，然后阻塞线程会放到阻塞队列里面。而pthead_cond_signal只是说让操作系统从阻塞队列唤醒一个线程。何来的信号丢失呢。你没看到pthead_cond_wait是放到信号处理函数里面进行等信号的吧。

[DoDoMouse]

引用 7 楼 pengzhixi 的回复:

[quote=引用 6 楼 u011761982 的回复:] [quote=引用 5 楼 pengzhixi 的回复:] 第一 你的pthread_cond_wait不是通过放到信号处理函数里面来实现这个功能的。这里所说的pthread_cond_signle发出的信号，你更多的应该看成是操作系统发出的一个通知，通知因为等待条件变量而陷入阻塞的进程。这里不是传统的信号处理。估计你的问题是如果pthread_cond_signle发出了通知，但是还没释放锁，这个时候wait得不到锁从而再次陷入阻塞，直到pthread_cond_signle线程释放锁之后才会wait成功。所以一般的建议是先释放锁 然后pthread_cond_signle。这样效率会比较高。

感谢回复。 如果被pthead_cond_signal那一边的代码先得到mutex，那就会存在这个信号丢失的问题啊。哪怕是先释放锁，然后再signal，这里面会有一个时间差，signal完毕的时候，如果wait那边的代码还没有进入状态，仍旧会得不到这个signal。除非这个signal在系统级别会对它进行处理，进行缓存。[/quote]看来你还是没理解啊，pthead_cond_signal不是说产生常规的信号啊，pthread_cond_wait只是把当前线程阻塞，然后在阻塞前释放mutex，然后阻塞线程会放到阻塞队列里面。而pthead_cond_signal只是说让操作系统从阻塞队列唤醒一个线程。何来的信号丢失呢。你没看到pthead_cond_wait是放到信号处理函数里面进行等信号的吧。[/quote] 那还是存在问题啊，如果先调用pthread_cond_signal了，操作系统去阻塞队列里面唤醒一个线程，可是这个时候那个该wait的线程还没有进入wait状态，即还没有进入阻塞队列，操作系统也就没有线程可以唤醒，于是这个操作其实就废掉了。

[pengzhixi]

引用 8 楼 u011761982 的回复:

[quote=引用 7 楼 pengzhixi 的回复:] [quote=引用 6 楼 u011761982 的回复:] [quote=引用 5 楼 pengzhixi 的回复:] 第一 你的pthread_cond_wait不是通过放到信号处理函数里面来实现这个功能的。这里所说的pthread_cond_signle发出的信号，你更多的应该看成是操作系统发出的一个通知，通知因为等待条件变量而陷入阻塞的进程。这里不是传统的信号处理。估计你的问题是如果pthread_cond_signle发出了通知，但是还没释放锁，这个时候wait得不到锁从而再次陷入阻塞，直到pthread_cond_signle线程释放锁之后才会wait成功。所以一般的建议是先释放锁 然后pthread_cond_signle。这样效率会比较高。

感谢回复。 如果被pthead_cond_signal那一边的代码先得到mutex，那就会存在这个信号丢失的问题啊。哪怕是先释放锁，然后再signal，这里面会有一个时间差，signal完毕的时候，如果wait那边的代码还没有进入状态，仍旧会得不到这个signal。除非这个signal在系统级别会对它进行处理，进行缓存。[/quote]看来你还是没理解啊，pthead_cond_signal不是说产生常规的信号啊，pthread_cond_wait只是把当前线程阻塞，然后在阻塞前释放mutex，然后阻塞线程会放到阻塞队列里面。而pthead_cond_signal只是说让操作系统从阻塞队列唤醒一个线程。何来的信号丢失呢。你没看到pthead_cond_wait是放到信号处理函数里面进行等信号的吧。[/quote] 那还是存在问题啊，如果先调用pthread_cond_signal了，操作系统去阻塞队列里面唤醒一个线程，可是这个时候那个该wait的线程还没有进入wait状态，即还没有进入阻塞队列，操作系统也就没有线程可以唤醒，于是这个操作其实就废掉了。[/quote] 你先调用pthread_cond_signal了那pthread_cond_wait就不需要阻塞了啊。你真的还是没理解啊