问题标签 [boost-mutex]

目前在我的代码中，我有这样的部分

我读到关键部分比互斥锁快？所以我正在做这样的事情，我想知道这是否更快。

第二种方法更快吗？我主要使用互斥锁的原因是为了防止竞争条件和锁定对方法的访问，以便一个线程一次访问它。有什么比这更快的吗？我的另一个担忧是关于声明

似乎每次调用 methodA() 都会在堆栈上创建锁。我正在考虑将锁声明为静态变量，因此每次调用此方法时都不会在堆栈上创建它。在这种情况下，我该如何添加 m_guard 到它。例如

我对认真使用互斥锁还很陌生。

在各个地方实现了几个互斥锁后，我意识到程序执行挂起（而不是退出）。我尝试调试它（在 Eclipse 环境中），但我无法找到明确的原因（或者至少我不知道如何找到一个）但是，我现在知道程序在尝试锁定后挂起几次迭代成功地在同一个地方锁定。

这里有一些代码：

我不知道死锁发生时会显示什么行为。1-这是一个僵局吗？

2-您会在哪里检查以查找原因？

3-同一互斥锁的递归锁定或嵌套锁定会导致这种情况吗？

这个可能是题外话：

4-I 在类之间交换互斥锁，以供不同线程在其方法中使用。这是一种常见的做法吗？允许这样的事情吗？

非常感谢您的意见和解决方案

我正在尝试使用 C++ 中的线程和互斥锁进行简单的提升。

这是代码：

在编译时，我收到此错误：

该错误仅在我尝试为仿函数创建线程时发生；直接执行它工作正常。此外，如果我删除对互斥锁和锁的所有引用，它就可以正常工作。

E：有错误的错误日志。哎呀。

I am new to boost threading (came from Win32 threading, which has probably ruined me).

So I'm trying to make a more "RAII" way to check that the working loop should still be going. So I made this simple function:

Is there a boost equivalent to this, since it seems like I'd use this all the time? Also it this an acceptable call?

The idea is to be able to safely do this without using a weirder lock:

I am trying to create a timed scoped lock on mutex. I thought following api from boost could help but I am having hard time finding some sample code as reference to use it.

I want to do it something like this,

My question is how to create a posix_time::ptime object of duration 200ms. I tried to create time_duration object but their is no constructor that accepts it straight forward way.

Can someone help me understand how it works please?

我似乎在同步数据收集时遇到问题。在这个特定的类中，我有一个数据集合、互斥体和条件变量，看起来像：

在大多数情况下，这是可行的。但是，最近我添加了一个函数，我基本上为集合中的每个值分配了一个新值。集合中大约有 100-200 个值，所以不是很多；所有的任务都发生得很快。我还确保在此步骤中不进行任何计算，这只是一系列作业。围绕作业，我有如下代码（基于stackoverflow上的答案）：

在代码的其他地方，我有一个从集合中“读取”信息的函数，它看起来像这样：

发生的事情是，当我的“写”函数被调用时，它似乎死锁了一段时间。它最终会打破它，所以它不是一个完整的死锁，但等待时间可能很长（几秒钟）。这应该是毫秒或更短的时间。

奇怪的是，我之前已经成功使用过上面的 writer 函数，并且有多个线程毫无问题地写入这个数据集合。我进行此更改的原因是将对该集合的更新集中到一个地方，而不是让它依赖于其他线程的运行时状态。

我正在使用 boost::mutex 类在一个资源上同步 2 个线程。当我调用以下boost:mutex:lock()函数时出现异常：

res = 22，即 EINVAL。当我查看手册页时，pthread_mutex_lock我可以看到该函数在以下情况下不会 EINVAL：

EINVAL：mutex 指定的值不引用已初始化的互斥对象。

此选项不相关，因为 boost:mutex 构造函数初始化 pthread_mutex_t。

EINVAL：互斥体是使用值为 PTHREAD_PRIO_PROTECT 的协议属性创建的，并且调用线程的优先级高于互斥体的当前优先级上限。

这个选项更合理。当您查看 boost::mutex custructor 中 pthread_mutex_t 的初始化时，您会看到：

这意味着 boost 使用pthread_mutexattr_t互斥锁的默认值。我的问题是：

1. 包含协议属性的默认值是否pthread_mutexattr_t具有 PTHREAD_PRIO_PROTECT 值？

2. 如果是你，我的问题会变得最糟糕，因为我依赖于尝试锁定互斥锁的线程优先级。我的线程是由创建的ACE_Task_Base::activate。你能告诉我ace默认线程优先级是什么吗？

我在linux redhat上运行...

好吧，我只是想使用 boost 将一些代码从 WIN32 应用程序移植到多平台应用程序。一切都很顺利，直到我遇到“WaitForMultipleObjects”问题。基本上，我有几个不同的 boost::recursive_mutexes 需要立即抓取。WaitForMultipleObjects 会在它们准备好时抓取它们，而不管顺序如何。

很长一段时间以来，这一直是一个缺失的功能，正如该线程中所述：

Boost 中的 WaitForMultipleObjects 功能

从那时起，有人找到解决问题的方法吗？

I've been using Boost in a DLL project but didn't export any Boost dependencies ...yet. Just C-Types and things which derive from the DLL Source tree itself.

But now I'm struggling with a lockable data model... I cannot get it designed exception safe and do not direct export boost types to the DLL interface.

And use it:

One could at least design probably some sort of DllTestData::Pimpl and hide the mutex type from the Dll. But If I want to use it like this:

While writing this I'm beginning to think about a ILockable-Interface and hide the mutex type in a PImpl or some sort, so something like this:

And use it like this:

Would this be a valid approach (hide mutex type with a pimpl and work with an Lockable interface) or am I going in the wrong direction with this? Or what would work better in this scenario? Maybe move the entire boost::mutex PImpl to the Interface?

我在 32 核计算机上运行以下程序：

1. 注释第 24、26 和 32 行需要 9 秒才能完成。
2. 只有第 24、26 行注释和 32 未注释，完成也需要 9 秒。
3. 没有注释行需要 18 秒才能完成

我认为这两个线程是独立的，是否有锁都没有关系a.foo()。但确实如此，为什么呢？