2

我正在构建一个基于 PCL 的应用程序，它使用 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。

4

1 回答 1

0

看看你的第二个代码片段，“main 中的部分”：

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

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

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

或者你打算使用

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

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

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

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

总结一下：除非您有意使用scoped_try_lock（实际上是一个内部帮助程序类 afaik），否则您可能打算使用scoped_lock.

于 2018-04-30T08:31:56.050 回答