【问题标题】:boost scoped_lock mutex crashesboost scoped_lock mutex 崩溃
【发布时间】:2011-02-22 08:15:57
【问题描述】:

我在这些函数中使用 boost::mutex 和 boost::mutex::scoped_lock 保护了 std::queue 的访问函数、push、pop、size

它有时会在作用域锁中崩溃

调用栈是这样的:

0  0x0040f005  boost::detail::win32::interlocked_bit_test_and_set  include/boost/thread/win32/thread_primitives.hpp  361
1  0x0040e879  boost::detail::basic_timed_mutex::timed_lock  include/boost/thread/win32/basic_timed_mutex.hpp  68
2  0x0040e9d3  boost::detail::basic_timed_mutex::lock  include/boost/thread/win32/basic_timed_mutex.hpp  64
3  0x0040b96b  boost::unique_lock<boost::mutex>::lock  include/boost/thread/locks.hpp  349
4  0x0040b998  unique_lock  include/boost/thread/locks.hpp  227
5  0x00403837  MyClass::inboxSize - this is my inboxSize function that uses this code:

MyClass::inboxSize ()
{
 boost::mutex::scoped_lock scoped_lock(m_inboxMutex);
 return m_inbox.size();
}

and the mutex is declared like this:
boost::mutex    m_inboxMutex;

它在此函数的最后粘贴行崩溃:

    inline bool interlocked_bit_test_and_set(long* x,long bit)
    {
        long const value=1<<bit;
        long old=*x;

x 有这个值:0xababac17

感谢您的帮助

【问题讨论】:

    标签: c++ multithreading boost


    【解决方案1】:

    x 的值在我看来很可疑。

    它看起来有点类似于 0xabababab,它可能是在调试模式下分配给分配内存的初始值,或者可能是保护值的一部分,用于指示分配的内存块是写在末尾还是开头

    你能追溯那个值是从哪里来的吗?

    【讨论】:

    • 我有点迷失在增强源中
    • 确实 x 的值比 0xabababab 多了 108 个字节。看起来极有可能MyClassm_inboxMutex 未初始化(或已销毁)。当 MyClass::inboxSize 崩溃时,尝试在 MyClass::inboxSize 的上下文中打印 this&amp;m_inboxMutex
    【解决方案2】:

    我认为您没有正确创建 MyClass 的实例。就像指向未正确初始化的 MyClass 的指针,然后以这种方式使用 ptr-&gt;inboxSize()

    【讨论】:

    • 实例没问题,调用的很多类的函数到此为止,我没有删除类
    • 使用成员数据的类函数?
    • 是的,使用成员数据的类函数,甚至是这个函数
    • 你怀疑 Boost.Thread 吗?老实说,我怀疑 Boost.Thread 是否存在问题。反正就是写个小测试。第一次测试。在一个线程中进行大量迭代,您可以使用scoped_lock 锁定和解锁mutex。然后是第二个测试。在多线程测试中锁定和解锁不同线程中的互斥锁。并告诉我们结果。
    猜你喜欢
    • 2011-01-17
    • 1970-01-01
    • 2014-08-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-11-06
    • 1970-01-01
    相关资源
    最近更新 更多