是否保证pthread_cond_signal会唤醒等待的线程?

pro*_*sor 12 c pthreads condition-variable

这是一个普遍的问题.例如,当前有两个子线程已经调用pthread_cond_wait(&cond1,&mutex),它们都在等待.然后,父线程调用

pthread_cond_signal(&cond1);
pthread_cond_signal(&cond1);
Run Code Online (Sandbox Code Playgroud)

接下来,我的问题是,是否保证两个等待线程都会被唤醒?(假设第一个线程被唤醒,稍后在执行的某个阶段释放互斥,以便第二个线程可以获取它).

我提出这个问题的原因是,对于Unix系统级信号,信号(比如说SIGCHLD)不排队,因此如果连续传送多个相同类型的信号可能会丢失.所以我想知道是否有pthread_cond_signal不同的实现,以便如果调度程序碰巧让父线程连续两次发出信号,它们不会丢失?

son*_*ave 13

快速回答:

pthread_cond_signal()将唤醒至少一个在条件变量上被阻塞的线程 - 但不能保证更多(参考,用于pthread_cond_broadcast()唤醒所有被阻塞的线程).

这里:

pthread_cond_signal()调用取消阻塞在指定条件变量cond上阻塞的至少一个线程(如果在cond上阻塞了任何线程).

pthread_cond_broadcast()调用取消阻止当前在指定条件变量cond上阻塞的所有线程.

答案越长:

因此,根据规范,我假设unblocking同步发生,也就是说,第一次调用pthread_cond_signal()未被阻塞的pthread_cond_signal()线程将被第二次调用视为未被阻塞,因此另一个线程将被唤醒起来.

但是,我不知道你的具体pthread实现是否属于这种情况(目前glibc网站非常狡猾,因此无法访问代码来查看).

可能还没有实现,但它在规范中的答案:

应该注意的是,最近对规范如何确定pthread_cond_signal()pthread_cond_broadcast()确定哪个线程在给定条件变量上实际被阻塞略有改写,但我认为并非所有实现都已赶上.

关于这个问题的长时间讨论可以在这里找到,新规范是:

pthread_cond_broadcast()和pthread_cond_signal()函数应以原子方式确定在指定的条件变量cond上阻塞哪些线程(如果有).此确定应在pthread_cond_broadcast()或pthread_cond_signal()调用期间的未指定时间发生.然后,pthread_cond_broadcast()函数将取消阻塞所有这些线程.pthread_cond_signal()函数将取消阻塞这些线程中的至少一个.

因此,结论是:如果不是规范的专家解释器,我会说新文本支持同步发生这种情况的假设 - 因此两个连续调用pthread_cond_signal()两个被阻塞的线程可用,将唤醒两个线程.

我对此并不是100%肯定,所以如果有人可以详细说明,请随意这样做.