条件变量、信号量、互斥锁实现生产者、消费者模式

本文探讨了条件变量+互斥锁在不定期命令输入场景中的局限,并介绍了使用信号量+互斥锁解决唤醒丢失问题的方法。通过实例展示了在高并发下如何避免生产者频繁唤醒但消费者未响应导致的问题。

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

一、条件变量+互斥锁

生产者

{

    unique_lock<mutex> lck(mutex);
       if(不满足生产条件)
	{
    	consume.wait(lck);
	}
        //执行生产操作
	produce.notify_all();
	lck.unlock();

}

消费者

{

	unique_lock<mutex> lck(zhmutex);
	while (不满足消费条件)
	{
        produce.wait(lck);
	}

      //执行消费操作

	consume.notify_all();
	lck.unlock();
   }

满足了如下的应用场景:线程等待不定期的命令输入,命令输入几秒一次

第二种应用场景:当生产者频繁输入,而消费者消费不及时,如果用上面的代码,会出现下面这种情况,生产者频繁写入,并唤醒条件变量,但是此时消费者没有等待唤醒,而是在执行耗时操作,则会出现唤醒丢失的情况,测试发现确实如此。

因此我考虑使用 信号量+互斥锁的方式,代码如下:

std::mutex zhmutex;

QSemaphore entrysem;

生产者

{

  unique_lock<mutex> lck(mutex);
    //生产操作 (仅对生产使用了信号量)
    lck.unlock();
    entrysem.release();

}

消费者

{

   entrysem.acquire();
    unique_lock<mutex> lck(zhmutex);

  //消费操作

    lck.unlock();

}

测试后发现,在消费者中加入耗时操作,比如 sleep,然后生产者频繁输入,消费者虽然因耗时操作消费较慢,但是不会出现唤醒丢失的情况。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值