我正在阅读pthread.h
;条件变量相关函数(如pthread_cond_wait(3)
)需要互斥体作为参数。为什么?据我所知,我将创建一个互斥锁仅用作该参数?那个互斥锁应该做什么?
10 回答
这只是条件变量(或最初)实现的方式。
互斥锁用于保护条件变量本身。这就是为什么在等待之前需要将其锁定的原因。
等待将“原子地”解锁互斥锁,允许其他人访问条件变量(用于信号)。然后当条件变量被发送或广播时,等待列表中的一个或多个线程将被唤醒,互斥锁将再次神奇地为该线程锁定。
您通常会看到以下带有条件变量的操作,说明它们是如何工作的。下面的例子是一个工作线程,它通过一个条件变量的信号来工作。
thread:
initialise.
lock mutex.
while thread not told to stop working:
wait on condvar using mutex.
if work is available to be done:
do the work.
unlock mutex.
clean up.
exit thread.
如果等待返回时有一些可用的,则在此循环中完成工作。当线程被标记为停止工作时(通常由另一个线程设置退出条件然后踢条件变量以唤醒该线程),循环将退出,互斥锁将被解锁并且该线程将退出。
上面的代码是一个单消费者模型,因为互斥体在工作完成时保持锁定状态。对于多消费者变体,您可以使用,例如:
thread:
initialise.
lock mutex.
while thread not told to stop working:
wait on condvar using mutex.
if work is available to be done:
copy work to thread local storage.
unlock mutex.
do the work.
lock mutex.
unlock mutex.
clean up.
exit thread.
这允许其他消费者在这个消费者工作时接收工作。
条件变量减轻了您轮询某些条件的负担,而是允许另一个线程在需要发生某些事情时通知您。另一个线程可以告诉该线程该工作可用,如下所示:
lock mutex.
flag work as available.
signal condition variable.
unlock mutex.
通常被错误地称为虚假唤醒的绝大多数通常总是因为在它们的pthread_cond_wait
调用(广播)中已发出多个线程的信号,一个线程将返回互斥锁,完成工作,然后重新等待。
然后当没有工作要做时,第二个信号线程可以出来。因此,您必须有一个额外的变量来指示应该完成的工作(这本质上是由 condvar/mutex 对在这里受到互斥保护的 - 但是,其他线程需要在更改互斥之前锁定互斥)。
从技术上讲,线程可以从条件等待中返回而不会被另一个进程踢(这是一个真正的虚假唤醒),但是,在我从事 pthreads 的所有这些年中,无论是在代码的开发/服务中还是作为用户其中,我从未收到过其中之一。也许这只是因为惠普有一个不错的实施:-)
在任何情况下,处理错误情况的相同代码也处理真正的虚假唤醒,因为不会为这些设置工作可用标志。
如果您只能发出条件信号,则条件变量非常有限,通常您需要处理一些与发出信号的条件相关的数据。信号/唤醒必须以原子方式完成,以在不引入竞争条件或过于复杂的情况下实现这一目标
出于技术原因,pthreads 还可以为您提供虚假的唤醒。这意味着您需要检查谓词,这样您就可以确定条件实际上已发出信号 - 并将其与虚假唤醒区分开来。检查关于等待它的条件需要被保护 - 因此条件变量需要一种在锁定/解锁保护该条件的互斥锁时自动等待/唤醒的方法。
考虑一个简单的示例,通知您生成了一些数据。也许另一个线程制作了一些您想要的数据,并设置了指向该数据的指针。
想象一个生产者线程通过“some_data”指针将一些数据提供给另一个消费者线程。
while(1) {
pthread_cond_wait(&cond); //imagine cond_wait did not have a mutex
char *data = some_data;
some_data = NULL;
handle(data);
}
您自然会遇到很多竞争条件,如果另一个线程在您醒来后立即执行some_data = new_data
,但在您醒来之前怎么办data = some_data
您也不能真正创建自己的互斥锁来保护这种情况。例如
while(1) {
pthread_cond_wait(&cond); //imagine cond_wait did not have a mutex
pthread_mutex_lock(&mutex);
char *data = some_data;
some_data = NULL;
pthread_mutex_unlock(&mutex);
handle(data);
}
不起作用,在醒来和抓住互斥锁之间仍有可能出现竞争条件。将互斥锁放在 pthread_cond_wait 之前对您没有帮助,因为您现在将在等待时持有互斥锁 - 即生产者将永远无法获取互斥锁。(注意,在这种情况下,您可以创建第二个条件变量来指示您已完成的生产者some_data
- 尽管这会变得复杂,特别是如果您想要许多生产者/消费者。)
因此,您需要一种在等待/从条件中唤醒时以原子方式释放/获取互斥锁的方法。这就是 pthread 条件变量所做的事情,这就是您要做的事情:
while(1) {
pthread_mutex_lock(&mutex);
while(some_data == NULL) { // predicate to acccount for spurious wakeups,would also
// make it robust if there were several consumers
pthread_cond_wait(&cond,&mutex); //atomically lock/unlock mutex
}
char *data = some_data;
some_data = NULL;
pthread_mutex_unlock(&mutex);
handle(data);
}
(生产者自然需要采取相同的预防措施,始终使用相同的互斥锁来保护“some_data”,并确保如果 some_data 当前为 != NULL,它不会覆盖 some_data)
POSIX 条件变量是无状态的。因此,维护状态是您的责任。由于等待的线程和告诉其他线程停止等待的线程都将访问该状态,因此它必须由互斥体保护。如果您认为可以在没有互斥锁的情况下使用条件变量,那么您还没有掌握条件变量是无状态的。
条件变量是围绕条件构建的。等待条件变量的线程正在等待某个条件。发出条件变量信号的线程会更改该条件。例如,一个线程可能正在等待一些数据到达。其他一些线程可能会注意到数据已经到达。“数据已到”是条件。
这是条件变量的经典用法,经过简化:
while(1)
{
pthread_mutex_lock(&work_mutex);
while (work_queue_empty()) // wait for work
pthread_cond_wait(&work_cv, &work_mutex);
work = get_work_from_queue(); // get work
pthread_mutex_unlock(&work_mutex);
do_work(work); // do that work
}
查看线程如何等待工作。作品受互斥体保护。等待释放互斥体,以便另一个线程可以给这个线程一些工作。以下是它的信号方式:
void AssignWork(WorkItem work)
{
pthread_mutex_lock(&work_mutex);
add_work_to_queue(work); // put work item on queue
pthread_cond_signal(&work_cv); // wake worker thread
pthread_mutex_unlock(&work_mutex);
}
请注意,您需要互斥锁来保护工作队列。请注意,条件变量本身不知道是否有工作。也就是说,条件变量必须与条件相关联,该条件必须由您的代码维护,并且由于它在线程之间共享,因此必须由互斥锁保护。
并非所有条件变量函数都需要互斥锁:只有等待操作才需要。信号和广播操作不需要互斥体。条件变量也不是与特定互斥锁永久关联的;外部互斥锁不保护条件变量。如果条件变量具有内部状态,例如等待线程的队列,则必须由条件变量内部的内部锁保护。
等待操作将条件变量和互斥锁结合在一起,因为:
- 一个线程锁定了互斥锁,对共享变量求值,发现它是假的,所以它需要等待。
- 线程必须以原子方式从拥有互斥锁转移到等待条件。
出于这个原因,等待操作将互斥锁和条件作为参数:以便它可以管理线程从拥有互斥锁到等待的原子传输,从而使线程不会成为丢失唤醒竞争条件的牺牲品。
如果线程放弃互斥锁,然后等待无状态同步对象,则会发生丢失唤醒竞争条件,但以一种非原子的方式:当线程不再拥有锁时,存在一个时间窗口,并且拥有尚未开始等待对象。在这个窗口期间,另一个线程可以进来,使等待的条件为真,发出无状态同步信号然后消失。无状态对象不记得它已发出信号(它是无状态的)。于是原来的线程在无状态同步对象上进入休眠状态,并没有唤醒,即使它需要的条件已经变为真:失去唤醒。
条件变量等待函数通过确保调用线程已注册以在它放弃互斥锁之前可靠地捕获唤醒来避免丢失唤醒。如果条件变量等待函数没有将互斥锁作为参数,这将是不可能的。
我没有发现其他答案像此页面那样简洁易读。通常,等待代码如下所示:
mutex.lock()
while(!check())
condition.wait(mutex) # atomically unlocks mutex and sleeps. Calls
# mutex.lock() once the thread wakes up.
mutex.unlock()
wait()
将 包装在互斥体中的三个原因:
- 如果没有互斥锁,另一个线程可以
signal()
在之前wait()
,我们会错过这个唤醒。 - 通常
check()
依赖于另一个线程的修改,所以无论如何你都需要互斥。 - 确保最高优先级的线程首先进行(互斥体的队列允许调度程序决定谁下一个)。
第三点并不总是值得关注的——从文章到这次谈话的历史背景是相关联的。
关于这种机制,人们经常提到虚假唤醒(即等待线程在没有signal()
被调用的情况下被唤醒)。但是,此类事件由 looped 处理check()
。
条件变量与互斥锁相关联,因为它是唯一可以避免它旨在避免的竞争的方法。
// incorrect usage:
// thread 1:
while (notDone) {
pthread_mutex_lock(&mutex);
bool ready = protectedReadyToRunVariable
pthread_mutex_unlock(&mutex);
if (ready) {
doWork();
} else {
pthread_cond_wait(&cond1); // invalid syntax: this SHOULD have a mutex
}
}
// signalling thread
// thread 2:
prepareToRunThread1();
pthread_mutex_lock(&mutex);
protectedReadyToRuNVariable = true;
pthread_mutex_unlock(&mutex);
pthread_cond_signal(&cond1);
Now, lets look at a particularly nasty interleaving of these operations
pthread_mutex_lock(&mutex);
bool ready = protectedReadyToRunVariable;
pthread_mutex_unlock(&mutex);
pthread_mutex_lock(&mutex);
protectedReadyToRuNVariable = true;
pthread_mutex_unlock(&mutex);
pthread_cond_signal(&cond1);
if (ready) {
pthread_cond_wait(&cond1); // uh o!
此时,没有线程会发出条件变量的信号,因此 thread1 将永远等待,即使 protectedReadyToRunVariable 表示它已准备好运行!
解决这个问题的唯一方法是让条件变量原子地释放互斥锁,同时开始等待条件变量。这就是 cond_wait 函数需要互斥锁的原因
// correct usage:
// thread 1:
while (notDone) {
pthread_mutex_lock(&mutex);
bool ready = protectedReadyToRunVariable
if (ready) {
pthread_mutex_unlock(&mutex);
doWork();
} else {
pthread_cond_wait(&mutex, &cond1);
}
}
// signalling thread
// thread 2:
prepareToRunThread1();
pthread_mutex_lock(&mutex);
protectedReadyToRuNVariable = true;
pthread_cond_signal(&mutex, &cond1);
pthread_mutex_unlock(&mutex);
调用时应该锁定互斥锁pthread_cond_wait
;当您以原子方式调用它时,它都会解锁互斥锁,然后在条件下阻塞。一旦发出条件信号,它就会以原子方式再次锁定它并返回。
如果需要,这允许实现可预测的调度,因为将执行信号发送的线程可以等到互斥锁被释放以执行其处理,然后发出条件信号。
这似乎是一个具体的设计决策,而不是概念上的需要。
根据 pthreads 文档,互斥锁未分离的原因是通过组合它们可以显着提高性能,并且他们希望由于常见的竞争条件,如果您不使用互斥锁,无论如何它几乎总是会完成。
https://linux.die.net/man/3/pthread_cond_wait </p>
互斥锁和条件变量的特点
有人建议将互斥锁的获取和释放与条件等待分离。这被拒绝了,因为实际上是操作的组合性质促进了实时实施。这些实现可以以对调用者透明的方式在条件变量和互斥锁之间自动移动高优先级线程。这可以防止额外的上下文切换,并在等待线程发出信号时提供对互斥锁的更具确定性的获取。因此,调度规则可以直接处理公平性和优先级问题。此外,当前条件等待操作符合现有实践。
对此有大量的注释,但我想用下面的例子来概括它。
1 void thr_child() {
2 done = 1;
3 pthread_cond_signal(&c);
4 }
5 void thr_parent() {
6 if (done == 0)
7 pthread_cond_wait(&c);
8 }
代码片段有什么问题?在继续之前稍微考虑一下。
这个问题真的很微妙。如果父级调用
thr_parent()
然后检查 的值done
,它将看到它是0
并因此尝试进入睡眠状态。但就在它调用等待进入睡眠之前,父母在 6-7 行之间被打断,孩子跑了。子进程将状态变量更改
done
为1
和信号,但没有线程在等待,因此没有线程被唤醒。当父级再次运行时,它永远处于休眠状态,这真是令人震惊。
如果它们是在单独获取锁时执行的呢?
如果您想要一个条件变量的真实示例,我在课堂上做了一个练习:
#include "stdio.h"
#include "stdlib.h"
#include "pthread.h"
#include "unistd.h"
int compteur = 0;
pthread_cond_t varCond = PTHREAD_COND_INITIALIZER;
pthread_mutex_t mutex_compteur;
void attenteSeuil(arg)
{
pthread_mutex_lock(&mutex_compteur);
while(compteur < 10)
{
printf("Compteur : %d<10 so i am waiting...\n", compteur);
pthread_cond_wait(&varCond, &mutex_compteur);
}
printf("I waited nicely and now the compteur = %d\n", compteur);
pthread_mutex_unlock(&mutex_compteur);
pthread_exit(NULL);
}
void incrementCompteur(arg)
{
while(1)
{
pthread_mutex_lock(&mutex_compteur);
if(compteur == 10)
{
printf("Compteur = 10\n");
pthread_cond_signal(&varCond);
pthread_mutex_unlock(&mutex_compteur);
pthread_exit(NULL);
}
else
{
printf("Compteur ++\n");
compteur++;
}
pthread_mutex_unlock(&mutex_compteur);
}
}
int main(int argc, char const *argv[])
{
int i;
pthread_t threads[2];
pthread_mutex_init(&mutex_compteur, NULL);
pthread_create(&threads[0], NULL, incrementCompteur, NULL);
pthread_create(&threads[1], NULL, attenteSeuil, NULL);
pthread_exit(NULL);
}