STD ::队列生产者/消费者的最小静音
我有两个线程可以使用std :: queue
的生产者和消费者方面。队列不经常满,所以我想避免消费者抓住正在守卫队列的静音的静音。
可以调用 empty()在穆特克斯外面,然后仅在队列中有东西时抓住utex?
例如:
struct MyData{
int a;
int b;
};
class SpeedyAccess{
public:
void AddDataFromThread1(MyData data){
const std::lock_guard<std::mutex> queueMutexLock(queueAccess);
workQueue.push(data);
}
void CheckFromThread2(){
if(!workQueue.empty()) // Un-protected access...is this dangerous?
{
queueAccess.lock();
MyData data = workQueue.front();
workQueue.pop();
queueAccess.unlock();
ExpensiveComputation(data);
}
}
private:
void ExpensiveComputation(MyData& data);
std::queue<MyData> workQueue;
std::mutex queueAccess;
}
线程2的检查和不是特别关键时期的检查,但会被称为 local (500/sec?)。线程1非常关键,很多东西需要在那里运行,但并不频繁地调用(最大20/秒)。
如果我围绕空()
添加一个静音罩,如果在线程2到达时队列为空,则不会长时间持有静音,因此可能不会很大。但是,由于它被如此频繁地打电话,因此偶尔可能同时发生某些事情是在试图放在背上的事情....这会导致线程1中的大量等待吗?
I have two threads that work the producer and consumer sides of a std::queue
. The queue isn't often full, so I'd like to avoid the consumer grabbing the mutex that is guarding mutating the queue.
Is it okay to call empty()
outside the mutex then only grab the mutex if there is something in the queue?
For example:
struct MyData{
int a;
int b;
};
class SpeedyAccess{
public:
void AddDataFromThread1(MyData data){
const std::lock_guard<std::mutex> queueMutexLock(queueAccess);
workQueue.push(data);
}
void CheckFromThread2(){
if(!workQueue.empty()) // Un-protected access...is this dangerous?
{
queueAccess.lock();
MyData data = workQueue.front();
workQueue.pop();
queueAccess.unlock();
ExpensiveComputation(data);
}
}
private:
void ExpensiveComputation(MyData& data);
std::queue<MyData> workQueue;
std::mutex queueAccess;
}
Thread 2 does the check and isn't particularly time-critical, but will get called a lot (500/sec?). Thread 1 is very time critical, a lot of stuff needs to run there, but isn't called as frequently (max 20/sec).
If I add a mutex guard around empty()
, if the queue is empty when thread 2 comes, it won't hold the mutex for long, so might not be a big hit. However, since it gets called so frequently, it might occasionally happen at the same time something is trying to get put on the back....will this cause a substantial amount of waiting in thread 1?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如上所述,您应仅在锁定下调用
empty()
。但是我相信有一种更好的方法。
您可以使用
std :: prenti其condition_variable
一起使用std :: mutex
,以实现同步访问队列的访问,而无需锁定静音的情况。但是 - 使用
std :: condition_variable
时,您必须意识到它遭受 spurious Wakeups 。您可以在此处阅读有关它的信息: spurious wakeup -wikipedia -wikipedia 。您可以在此处查看一些代码示例:条件变量示例。
下面说明了使用
std :: procenty_variable
的正确方法(带有一些注释)。这只是显示原则的一个最小例子。
一些注释:
mtx
,q
等)最好是某些上下文类的成员,或传递给producer()
and <代码>消费者()作为参数。condition_variable
时提取Q中的所有元素来使其更加笼统。sleep_for
时间来“播放”生产者和消费者测试VARIOS时序案例的时间。到:
为了提高效率(由于队列中的正面元素是
pop
之后,无论如何)。mydata
是默认可构造的。如果不是这种情况,您可以在消费者的环体中使用立即调用的lambda :
使用
std :: Move
与NRVO一起使用效率。As written in the comments above, you should call
empty()
only under a lock.But I believe there is a better way to do it.
You can use a
std::condition_variable
together with astd::mutex
, to achieve synchronization of access to the queue, without locking the mutex more than you must.However - when using
std::condition_variable
, you must be aware that it suffers from spurious wakeups. You can read about it here: Spurious wakeup - Wikipedia.You can see some code examples here: Condition variable examples.
The correct way to use a
std::condition_variable
is demonstrated below (with some comments).This is just a minimal example to show the principle.
Some notes:
mtx
,q
etc.) are better to be members of some context class, or passed to theproducer()
andconsumer()
as parameters.condition_variable
is signaled.sleep_for
times for the producer and consumer to test varios timing cases.to:
for better efficiency (since the front element in the queue is
pop
ed right afterwards anyway).MyData
is default constructable.If this is not the case, you can use an immediatly invoked lambda in the loop body in the consumer:
The usage of
std::move
together with NRVO should make it efficient.