其他项目调用的boost :: mutex会导致访问冲突

时间:2018-05-24 17:16:00

标签: c++ boost mutex

我正在开发一个包含2个项目的解决方案,一个使用v80工具集(C ++ 98)构建的.DLL和一个使用v110工具集(早期C ++ 11)的.EXE。原因是解决方案逐步迁移到C ++ 11,而v80 .DLL仍然具有阻止升级的依赖关系。这最终将得到解决,同时......

v80 .DLL监听网络,排队事件(稍后由v110 .EXE消化)并使用boost :: mutex控制队列的访问。两个项目都使用相同版本的增强资产(ms80为1.58.8.6)。

当v80 EventListener类锁定互斥锁时,似乎没有问题。为了测试它,我一直在使用EventListener构造函数中的互斥锁调用成员方法。 Scoped锁定和对lock()/ unlock()的调用正常运行。

问题:

当v110 Dispatcher调用EventListener的方法(类如clearQueue()或~EventListener()锁定互斥锁时)我在尝试锁定互斥锁时遇到访问冲突错误。这一行给出了错误:

// in boost\thread\win32\thread_primitive.hpp
inline bool interlocked_bit_test_and_set(long* x,long bit)
{
    return _interlockedbittestandset(x,bit)!=0;  <-- 0xC0000005: Access violation writing location 0x00EC1644
}

一些额外的细节:

  • 互斥锁类成员是在构造函数初始化时使用boost::mutex*初始化的new boost::mutex()
  • 当互斥锁被锁定时,它位于boost::mutex::scoped_lock lock(*mQueueMutex);

我想,也许当v110 .EXE进行调用时,_interlockedbittestandset调用的上下文/权限不同,可能会导致错误...但我没有任何内容到目前为止,支持这一理论。

修改

我自己想出了一个简单,完整且可验证的示例,但我无法重新创建问题。我必须说这是一个伟大的反思练习来做出这个例子并试图解决这个问题,它也比我想象的要快!

我强烈建议任何人在发布此帖之前先尝试一下,并向任何感受到帖子垃圾邮件的人提供谦卑的道歉。

现在,我会试着找出真正的问题所在。

v110代码

#include <iostream>
#include <thread>
#include "../BoostMutexTest/MutexOwningClass_v80.h"

void work(MutexOwningClass_v80* m)
{
  m->lockMutex();
}

void main()
{
  MutexOwningClass_v80* v80_Class = new MutexOwningClass_v80();

  std::thread t1(&work,v80_Class);
  std::thread t2(&work,v80_Class);
  std::thread t3(&work,v80_Class);
  std::thread t4(&work,v80_Class);

  t1.join();
  t2.join();
  t3.join();
  t4.join();
}

v80代码

#include "boost/thread.hpp"

struct MutexOwningClass_v80
{
  MutexOwningClass_v80();
  void lockMutex();
private:
  boost::mutex* m;
};

#include "MutexOwningClass_v80.h"
#include <iostream>

MutexOwningClass_v80::MutexOwningClass_v80(): m(new boost::mutex())
{}

void MutexOwningClass_v80::lockMutex()
{
  boost::mutex::scoped_lock lock(*m);
  std::cout << "My mutex is locked!" << std::endl; 
}

输出(不出所料......)

My mutex is locked!
My mutex is locked!
My mutex is locked!
My mutex is locked!

0 个答案:

没有答案