Question

我正在构建一个基于PCL的应用程序，为此使用了可以看到here的velodyne的默认PCL抓取器代码。

当我在调试模式下构建我的应用程序时，它按照预期工作，但在发布版本中，云正在跳过，我松开了一两个云。我缩小了这个事实，即我没有经验的互斥锁存在一些问题。

// Retrieved Point Cloud Callback Function
boost::mutex mutex;
boost::function<void(const pcl::PointCloud<PointType>::ConstPtr&)> function =[&cloud, &mutex](const pcl::PointCloud<PointType>::ConstPtr& ptr)
{
    boost::mutex::scoped_lock lock(mutex);
    // Point Cloud Processing
    cloud = ptr;
};

这是接收我的云的回调，下面的部分是主要的

while (!viewer->wasStopped())
{
    viewer->spinOnce(); // Update Viewer
    tStart = clock();
    boost::mutex::scoped_try_lock  lock(mutex);

我无法弄清楚为什么发布与调试存在差异。有什么建议？我使用Visual Studio 2017和PCL 1.8.1。

Answer 1

查看您的第二个代码段，＆＃34;主要部分＆＃34;中的部分：

boost::mutex::scoped_try_lock lock(mutex);

让我困惑。 try_lock将尝试来锁定互斥锁。如果互斥锁当前正在使用，它将无法锁定互斥锁并继续执行。互斥锁之后的块可能受到互斥锁的保护，也可能不受互斥锁保护。

这真的是你想要做的吗？你检查了锁的状态吗？

或者您打算使用

boost::mutex::scoped_lock lock(mutex);

这将阻止线程执行，直到它可以访问互斥锁。此语句后的块将始终受互斥锁保护。

使用try_lock会发生的情况是，如果它无法锁定互斥锁，则执行将在没有锁定的情况下继续。您有责任处理此案件。如果你不这样做，互斥锁将完全失效，你将遇到竞争条件，不安全的并发访问和其他问题。

这也可能是您的程序在发布中的行为与在调试中表现不同的原因。在发布时，程序的某些部分运行得更快，因此时序行为完全不同。可能是在Debug中，时间是这样的，即永远不会同时访问互斥锁要保护的数据结构。但在发布时，这将完全不同。

总结一下：除非你故意使用scoped_try_lock（实际上是内部助手类afaik），否则你可能想要使用scoped_lock。

boost :: mutex发布VS Debug Build

1 个答案: