在多线程程序中查找冲突的存储/加载

Question

我试图用boost::asio和多个线程编写一个程序。这个程序似乎运行得很好，但是当我使用val研线程工具drd运行它时，我会收到与存储和加载操作冲突的消息。

==13740==线程2：==13740==冲突存储线程2在0x06265ff0大小4 ==13740== 0x40F2B8：==13740== int) (epoll_reactor.hpp:68) ==13740== by 0x410097: boost::asio::detail::epoll_reactor::run(bool，boost::asio::detail::op_queue&) (epoll_reactor.ipp:430)

等。

由于所有涉及的boost调用，错误消息相当长，而且似乎没有直接包含我的函数。正如我所说的，这个程序看起来很有效，但是把这些错误留在代码中会让我有一种不好的感觉。有什么好的方法可以找到代码中有问题的位置吗？

谢谢你的建议

Answer 1

一个相关的bug报告落在了Ubuntu的bug跟踪器(，而不是，IYAM的正确位置)：

• https://bugs.launchpad.net/ubuntu/+source/boost1.53/+bug/1243570 这将详细说明在Hel差市(而不是DRD)检测到的锁顺序冲突。这是比较有形的
• 一些旧的，但可能有有趣的讨论在这里：http://lists.boost.org/Archives/boost/2010/06/167818.php 我对这个源代码的评论如下：

- The comments at the bottom of class epoll\_reactor say that any    access of registered\_descriptors\_ should be protected by    registered\_descriptors\_mutex\_. However, the method shutdown\_service()    modifies the container registered\_descriptors\_ but doesn't lock    registered\_descriptors\_mutex\_. 
- The method epoll\_reactor::register\_descriptor() modifies its second    argument (descriptor\_data) such that it points to the newly created    descriptor\_state object. All data members of the struct    descriptor\_state are public, but all accesses must be guarded by a    lock on descriptor\_state::mutex\_. So all callers of    register\_descriptor() must be checked in order to verify whether or    not there are any thread-unsafe accesses of    descriptor\_state::op\_queue\_ or descriptor\_state::shutdown\_. Personally    I never recommended such a class design. 
- While all accesses of the members of struct descriptor\_state should    be protected by locking descriptor\_state::mutex\_, no lock is held on    this last mutex by register\_descriptor() when it sets    descriptor\_data::shutdown\_ nor by shutdown\_service() while it modifies    descriptor\_state::op\_queue\_ and descriptor\_state::shutdown\_. The    former is easy to fix: move the "descriptor\_data->shutdown\_ = false"    statement to somewhere before the epoll\_ctl() system call. 

上述情况之一是否解释了您所观察到的竞赛报告？

当然，从那时起已经通过了许多版本(1.43.0-1.55.0)，所以很可能已经解决了这个问题，或者进行了其他更改，但是它可以帮助您在boost跟踪器中找到更多的信息？