操作系统:线程间的同步->【转】条件变量(Condition Variable)详解

本文通过一个具体实例介绍了条件变量在多线程程序中的作用,并对比了条件变量与轮询两种方式的优劣。同时,详细分析了条件变量的正确使用方法及注意事项。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

若单单用互斥锁来实现资源互斥访问的机制(线程A在访问C资源的时候,线程B对资源不能访问),会出现死锁:线程A对mutex1执行关锁,进入临界区C,在临界区C中,他又要访问临界区中的资源R。但与此同时R正处于忙碌处于关锁状态,保持了资源R的线程B现在也想要进入临界区C。那么就出现了死锁。A想要用R,保持R的B要进入临界区C。永远不会unlock啦。那就需要用条件变量了。

以下转自:http://www.wuzesheng.com/?p=1668

条件变量(Condtion Variable)是在多线程程序中用来实现“等待->唤醒”逻辑常用的方法。举个简单的例子,应用程序A中包含两个线程t1和t2。t1需要在bool变量test_cond为true时才能继续执行,而test_cond的值是由t2来改变的,这种情况下,如何来写程序呢?可供选择的方案有两种:

  • 第一种是t1定时的去轮询变量test_cond,如果test_cond为false,则继续休眠;如果test_cond为true,则开始执行。
  • 第二种就是上面提到的条件变量,t1在test_cond为false时调用cond_wait进行等待,t2在改变test_cond的值后,调用cond_signal,唤醒在等待中的t1,告诉t1 test_cond的值变了,这样t1便可继续往下执行。

          很明显,上面两种方案中,第二种方案是比较优的。在第一种方案中,在每次轮询时,如果t1休眠的时间比较短,会导致cpu浪费很厉害;如果t1休眠的时间比较长,又会导致应用逻辑处理不够及时,致使应用程序性能下降。第二种方案就是为了解决轮询的弊端而生的。然而条件变量在使用的过程中,比较容易出错,如何用得不正确的话,会适得其反的,接下来,我将详细分析如何来使用条件变量,希望能够给在使用条件变量过程中遇到问题的朋友有所帮助。
          在开始介绍之前,需要说明一下,在接下来的介绍中,需要用到互斥锁和条件变量相关的内容,在这里我以linux下的pthread_mutex_t为互斥锁类型,pthread_cond_t为条件变量类型来进行介绍,对pthread不熟的朋友,可以参考一下linux下的manual。

    pthread_mutex_t mutex;  ///< 互斥锁
    pthread_cond_t  cond;   ///< 条件变量
    bool test_cond = false;
    /// TODO 初始化mutex和cond
     
    /// thread 1:
    pthread_mutex_lock(&mutex);            ///< 1
    while (!test_cond)
    {
        pthread_cond_wait(&cond, &mutex);  ///< 2,3
    }
    pthread_mutex_unlock(&mutex);          ///< 4
    RunThread1Func();
     
    /// thread 2:
    pthread_mutex_lock(&mutex);            ///< 5
    test_cond = true;
    pthread_cond_signal(&cond);
    pthread_mutex_unlock(&mutex);          ///< 6
     
    /// TODO 销毁mutex和cond


    通过上面的例子,下面我来介绍一下条件变量在使用过程中需要注意的几点(也是比较容易出错的):
          (1)条件变量的使用过程中,最为关键的一点是互斥锁的使用。细心的朋友应该发现了,我在上面的例子中标了1、2、3、4、5、6个标号。在这里1、4、5、6都是正常的lock/unlock,2、3是需要特别说明的。2是进入pthread_cond_wait后的,pthread_cond_wait调的pthread_mutex_unlock,这样做的目的是为了保证在thread1阻塞wait后,thread2获取同一把锁mutex的时候,能够正常获取(即5,6)。3是thread1被唤醒后,要退出pthead_cond_wait之前,pthread_cond_wait调的pthread_mutex_lock,这样做的目的是为了把mutex的控制权还给调用pthread_cond_wait的线程(即thread1)。整理一下基本的时序为:

    thread 1 lock->thread 1 wait-> thread 1 unlock(in wait)
    ->thread 2 lock->thread 2 signal->thread 2 unlock
    ->thread 1 lock(in wait)->thread 1 unlock

    (2)条件变量使用的过程中,通常会加一个bool或者int的值test_cond来配合使用。这里需要注意的一点是一定要在signal之前来改变test_cond,这样才能保证wait的线程被唤醒后,能够取到正确的test_cond的值,否则后果是不可预测的。



UDS(统一诊断服务)是在车辆中使用的一种通信协议,它是基于ISO 14229标准开发的,用于车辆的诊断通信。在UDS中,数据的传输涉及多种不同类型的,包括连续帧和多等。 连续帧(Flow Control Frame):在处理较大的数据传输时,如果数据量超过了能够承载的大小,就需要将数据分割成多个来传输。连续帧用于标记一个数据消息的多个的连续部分。它们通常会包含一个连续帧计数器,这个计数器会指明当前是该消息中的第几,以及消息总共有多少(Flow Control Frame):用于制数据的发送速率,确保发送端和接收端的数据处理能够匹配。可以是正向的,比如发送方请求继续发送更多的数据,也可以是反向的,比如接收方请求发送方减慢发送速度或者暂停发送。在UDS中,制通常通过发送特定的消息(如ISO 14229-3中定义的和连续帧)来实现。 多(Multi Frame):当传输的数据量超过一个的最大数据载荷时,就需要使用多传输。多传输涉及到将数据分成多个连续的,每个都有序号和总数的信息,接收方通过这些信息将多个重新组合成原始的数据消息。 在使用多传输时,发送方和接收方之间的通信需要有相应的协议来确保数据的完整性和顺序性。如果在数据传输过程中,接收方没有正确地接收到某个,它可以通过发送来请求重传那个特定的
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值