没有为pthread_cond_timedwait和pthread_cond_signal锁定互斥锁(在Linux上)

Question

调用pthread_cond_timedwait是否有任何缺点,而不首先锁定相关的互斥锁,并且在调用pthread_cond_signal时也不会使用互斥锁？

在我的情况下,确实没有条件要检查,我想要一个非常类似于Java wait(long)和notify()的行为.

根据文档,可能存在"不可预测的调度行为".我不确定这意味着什么.

一个示例程序似乎工作正常,而不首先锁定互斥锁.

Answer 1

第一个不行:

的pthread_cond_timedwait()和 pthread_cond_wait()功能应在条件变量阻塞.它们应该被调用线程锁定的互斥锁或未定义的行为结果调用.

http://opengroup.org/onlinepubs/009695399/functions/pthread_cond_timedwait.html

原因是实现可能希望依赖锁定的互斥锁,以便安全地将您添加到服务器列表中.它可能想要在没有先检查它的情况下释放互斥锁.

第二个是令人不安的:

如果需要可预测的调度行为,那么该互斥锁被线程调用pthread_cond_signal()或 锁定 pthread_cond_broadcast().

http://www.opengroup.org/onlinepubs/007908775/xsh/pthread_cond_signal.html

我不知道具体的竞争条件会影响调度程序的行为,如果你发出警告而不采取锁定的话.所以我不知道未定义的调度程序行为有多糟糕:例如,对于广播,服务员只是没有按优先级顺序获取锁(或者您的特定调度程序通常表现).或者也许服务员会"迷失".

但是,通常情况下,使用条件变量,您需要设置条件(至少是标志)和信号,而不仅仅是信号,为此您需要使用互斥锁.原因是否则,如果你与另一个调用wait()的线程并发,那么你会根据wait()或signal()获胜而获得完全不同的行为:如果signal()先偷偷摸摸,那么你将会即使您关心的信号已经发生,也要等待完全超时.这很少是条件变量的用户想要的,但可能对你没问题.也许这就是文档所说的"不可预测的调度程序行为" - 突然间,时间片对于程序的行为变得至关重要.

顺便说一下,在Java中你必须拥有锁才能通知()或notifyAll():

此方法只应由作为此对象监视器所有者的线程调用.

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#notify()

Java synchronized {/}/wait/notifty/notifyAll行为类似于pthread_mutex_lock/pthread_mutex_unlock/pthread_cond_wait/pthread_cond_signal/pthread_cond_broadcast,而不是巧合.

Answer 2

Butenhof出色的"使用POSIX线程编程"在第3.3.3章末尾对此进行了讨论.

基本上,在不锁定互斥锁的情况下发信号通知condvar是一种潜在的性能优化:如果信令线程已锁定互斥锁,则在condvar上唤醒的线程必须立即阻塞信令线程锁定的互斥锁,即使信令线程是不修改等待线程将使用的任何数据.

提到"不可预测的调度程序行为"的原因是,如果您有一个高优先级线程在condvar上等待(另一个线程将发出信号并唤醒高优先级线程),任何其他优先级较低的线程都可以来锁定互斥锁,以便在发出condvar信号并唤醒高优先级线程时,它必须等待优先级较低的线程释放互斥锁.如果在发信号时锁定互斥锁,那么优先级较高的线程将在优先级较低的线程之前在互斥锁上进行调度:基本上你知道当你"唤醒"高优先级线程时,它会在调度程序中立即唤醒允许它(当然,您可能必须在发出高优先级线程之前等待互斥锁,但这是一个不同的问题).