没有锁定的那么pthread_cond_timedwait和pthread_cond_signal会（在Linux上）互斥 [英] Not locking mutex for pthread_cond_timedwait and pthread_cond_signal ( on Linux )

问题描述

是否有任何缺点调用不那么pthread_cond_timedwait首先采取锁关联的互斥锁，并调用pthread_cond_signal会时也没有采取互斥锁？

Is there any downside to calling pthread_cond_timedwait without taking a lock on the associated mutex first, and also not taking a mutex lock when calling pthread_cond_signal ?

在我的情况下，实在没有条件来检查，我想非常类似于Java等待（长）行为和notify（）。

In my case there is really no condition to check, I want a behavior very similar to Java wait(long) and notify().

根据该文件，可以有UN predictable调度行为。我不知道这意味着什么。

According to the documentation, there can be "unpredictable scheduling behavior". I am not sure what that means.

这是示例程序似乎很好地工作，而不首先锁定互斥。

An example program seems to work fine without locking the mutexes first.

推荐答案

首先是不正常：

的那么pthread_cond_timedwait（）和
  调用pthread_cond_wait（）职责
  阻止在一个条件变量。他们
  应通过互斥锁被称为
  调用线程或未定义
  行为的结果。

The pthread_cond_timedwait() and pthread_cond_wait() functions shall block on a condition variable. They shall be called with mutex locked by the calling thread or undefined behavior results.

<一个href=\"http://opengroup.org/onlinepubs/009695399/functions/pthread_cond_timedwait.html\">http://opengroup.org/onlinepubs/009695399/functions/pthread_cond_timedwait.html

原因是，实施可能要依赖于互斥被锁定，以便安全地添加到一个服务员名单。它可能要释放的互斥体没有检查它是举行。

The reason is that the implementation may want to rely on the mutex being locked in order to safely add you to a waiter list. And it may want to release the mutex without first checking it is held.

二是令人不安的：

如果predictable调度行为
  要求，则该互斥已被锁定
  线程调用
  调用pthread_cond_signal（）或
  调用pthread_cond_broadcast（）。

if predictable scheduling behaviour is required, then that mutex is locked by the thread calling pthread_cond_signal() or pthread_cond_broadcast().

<一个href=\"http://www.opengroup.org/onlinepubs/007908775/xsh/pthread_cond_signal.html\">http://www.opengroup.org/onlinepubs/007908775/xsh/pthread_cond_signal.html

关闭我的头顶，我不知道具体的竞争条件是什么，如果你没有采取锁定信号，即弄乱调度的行为。所以我不知道不确定调度行为多么糟糕：例如可能与广播，服务员只是没有得到优先顺序（或者不管你的特殊的调度行为正常）锁。或者，也许服务员可以得到丢失。

Off the top of my head, I'm not sure what the specific race condition is that messes up scheduler behaviour if you signal without taking the lock. So I don't know how bad the undefined scheduler behaviour can get: for instance maybe with broadcast the waiters just don't get the lock in priority order (or however your particular scheduler normally behaves). Or maybe waiters can get "lost".

一般情况下，虽然与条件变量要设置条件（至少一个标志）和信号，而不仅仅是信号，为此，你需要采取的互斥。其原因是，否则，如果你是并发另一个线程调用wait（），然后你根据是否等待（）或信号（）胜得到完全不同的行为：如果信号（）在第一次钻进，那么你会等待，即使你关心的信号已经发生了长暂停。这是很少的条件变量的用户想要什么，但可能会替你安排。或许，这就是该文档的联合国predictable调度行为是什么意思 - 突然变成时间片到你的程序的行为至关重要

Generally, though, with a condition variable you want to set the condition (at least a flag) and signal, rather than just signal, and for this you need to take the mutex. The reason is that otherwise, if you're concurrent with another thread calling wait(), then you get completely different behaviour according to whether wait() or signal() wins: if the signal() sneaks in first, then you'll wait for the full timeout even though the signal you care about has already happened. That's rarely what users of condition variables want, but may be fine for you. Perhaps this is what the docs mean by "unpredictable scheduler behaviour" - suddenly the timeslice becomes critical to the behaviour of your program.

顺便说一下，在Java中，你必须有锁，以通知（）或notifyAll的（）：

Btw, in Java you have to have the lock in order to notify() or notifyAll():

此方法应该仅由一个被称为
  螺纹是这样的所有者
  对象的监视器。

This method should only be called by a thread that is the owner of this object's monitor.

<一个href=\"http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#notify()\">http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#notify()

同步在Java {/} /等待/ notifty / notifyAll的行为类似于pthread_mutex_lock/pthread_mutex_unlock/pthread_cond_wait/pthread_cond_signal/pthread_cond_broadcast,而不是巧合。

The Java synchronized {/}/wait/notifty/notifyAll behaviour is analogous to pthread_mutex_lock/pthread_mutex_unlock/pthread_cond_wait/pthread_cond_signal/pthread_cond_broadcast, and not by coincidence.

这篇关于没有锁定的那么pthread_cond_timedwait和pthread_cond_signal会（在Linux上）互斥的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！