C++:线程同步

发布于 2024-11-06 06:43:11 字数 1131 浏览 1 评论 0原文

我正在尝试使用 Boost 库同步两个线程(在同一个 C++ 映射上工作)。我必须指出,我不是 C++ 专家,而且我发现 boost 文档很难理解。

我想要实现的目标是这样的:

#Thread 1
get access to the map
put in something
release access 

#Thread 2
wait until map is empty
when it's not empty anymore, wake up and gain access
perform operations on one entry of the map
leave access to somebody else

我尝试使用互斥体和条件变量,但代码无法正常工作。具体来说,当 thread2 醒来时(在等待 cond. 变量之后),它没有直接访问映射,但有其他人获得了访问权限并清空了映射。因此,我遇到了分段错误,因为我期望地图是满的,而当我访问它时它是空的。

此外,我想了解诸如 mymutex.lock() 之类的东西和诸如 boost::mutex::scoped_lockscopedLock(mutex_); 之类的调用之间的区别。 或unique_lock

感谢您的教学:)

编辑:在这里我尝试提取代码的相关部分。由于我不太了解同步是如何工作的,所以它可能没有多大意义......

//COMMON PART
boost::mutex mutex1;
boost::mutex mutex2;
boost::condition_variable cond;
boost::mutex::scoped_lock mutex2lock(mutex2);

//THREAD 1
...
if(someCondition){
    mutex1.lock();
    map[id]=message;
    cond.notify_one();
    mutex1.unlock();
}
...


//THREAD 2
...
cond.wait(mutex2lock);
mutex.lock();
//Perform operation on map[id]
doSomething(map[id]));
mutex.unlock();
...

I am trying to synchronize two thread (working on the same C++ map) using the Boost library. I must tell that I am not an expert in C++ and I find the boost documentation quite hard to understand.

What I want to achieve, is something like this:

#Thread 1
get access to the map
put in something
release access 

#Thread 2
wait until map is empty
when it's not empty anymore, wake up and gain access
perform operations on one entry of the map
leave access to somebody else

I tried to use Mutex and condition_variables, but the code was not working properly. In specific, when thread2 was waking up (after waiting the cond. variable), it was not gaining directly access to the map, but there was somebody else that got access and emptied the map. Therefore, I got segmentation fault, because I was expecting the map to be full while it was empty when I accessed it.

In addition, I would like to understand the difference between something like mymutex.lock() and invokations like boost::mutex::scoped_lock scopedLock(mutex_);
or unique_lock.

Thanks for teaching :)

EDIT: here I tried to extract the relevant parts of my code. Since I did not understand very well how sync works, it may not make much sense...

//COMMON PART
boost::mutex mutex1;
boost::mutex mutex2;
boost::condition_variable cond;
boost::mutex::scoped_lock mutex2lock(mutex2);

//THREAD 1
...
if(someCondition){
    mutex1.lock();
    map[id]=message;
    cond.notify_one();
    mutex1.unlock();
}
...


//THREAD 2
...
cond.wait(mutex2lock);
mutex.lock();
//Perform operation on map[id]
doSomething(map[id]));
mutex.unlock();
...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

一个人的夜不怕黑 2024-11-13 06:43:11

此外,我还想
了解之间的区别
类似 mymutex.lock() 和
像这样的调用
boost::mutex::scoped_lock
作用域锁(mutex_);或 unique_lock。

Google 搜索“c++ RAII”:

使用 mymutex.lock() 您可以“手动”锁定互斥体。 (稍后必须“手动”解锁它。)

scoped_lock 是一个帮助程序类,它为您执行锁定以及在其作用域结束时自动解锁。

In addition, I would like to
understand the difference between
something like mymutex.lock() and
invokations like
boost::mutex::scoped_lock
scopedLock(mutex_); or unique_lock.

Google for "c++ RAII":

With mymutex.lock() you are "manually" locking the mutex. (And later have to unlock it "manually".)

scoped_lock is a helper class that does locking - and automatic unlocking at end of its scope - for you.

╄→承喏 2024-11-13 06:43:11
boost::mutex::scoped_lock mutex2lock(mutex2);

如果我理解正确的话,这应该是 mutex2 上的一个大锁,它将持续你的 Mutex 的长度。

可能您希望在第二个线程的上下文中获得该锁,但我不太明白为什么 condition_variable 需要它。

事实上,阅读文档后,condition_variable 本身对于您所做的事情似乎有点错误:

以原子方式调用 lock.unlock() 并阻止当前线程。当通过调用 this->notify_one() 或 this->notify_all() 或虚假

通知时,线程将解除阻塞

在我看来,该描述表明,当它认为可以解锁时,它就可以解锁运行(可能基于时间) 看来您可能需要检查列表是否有效,如果不有效,如果您打算使用condition_variable,请再次调用 wait 。

boost::mutex::scoped_lock mutex2lock(mutex2);

This should, if I understand correctly, but a big lock on mutex2 that'll last the length of your Mutex.

Likely you want that lock within the context of the second thread, but I don't much understand why condition_variable wants it.

In fact, it seems that condition_variable itself is a bit wrong for what you are doing, reading the documentation:

Atomically call lock.unlock() and blocks the current thread. The thread will unblock when notified by a call to this->notify_one() or this->notify_all(), or spuriously

That description seems to me that it can just unlock when it feels it can run (likely based on time) It seems you would likely need to check to see if you the list is valid, and if not, call wait again, if you plan to use condition_variable.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文