boost :: mutex Release VS Debug Build - PullRequest
       22

boost :: mutex Release VS Debug Build

0 голосов
/ 30 апреля 2018

Я создаю приложение на базе PCL, для которого используется код граббера PCL по умолчанию для velodyne, который можно увидеть здесь .

Когда я собираю свое приложение в режиме отладки, оно работает в соответствии с ожиданиями, но в сборке выпуска облака пропускаются, и я теряю одно или два облака. Я сузился до того факта, что с мьютексом есть проблема, с которой у меня нет опыта.

// 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.

1 Ответ

0 голосов
/ 30 апреля 2018

Взгляните на ваш второй фрагмент кода, "часть в основном":

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

смущает меня здесь. try_lock будет пытаться заблокировать мьютекс. Он не сможет заблокировать мьютекс и продолжить выполнение, если мьютекс используется в данный момент. Блок после мьютекса может быть защищен или не защищен мьютексом.

Это действительно то, что вы хотите сделать? Вы проверяли статус блокировки?

Или вы намеревались использовать

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

Это блокирует выполнение потоков, пока не получит доступ к мьютексу. Блок после этого оператора всегда будет защищен мьютексом.

При try_lock происходит следующее: если он не может заблокировать мьютекс, выполнение будет продолжено без блокировки. Вы несете ответственность за рассмотрение этого дела. Если вы этого не сделаете, мьютекс будет полностью неэффективным, и у вас будут условия гонки, небезопасный одновременный доступ и другие проблемы.

Это также может быть причиной того, что ваша программа ведет себя иначе в выпуске, чем в отладке. В выпуске определенные части программы работают намного быстрее, поэтому временные характеристики совершенно иные. Может случиться так, что в Debug время будет таким, что никогда не будет одновременного доступа к структуре данных, которую мьютекс должен защищать. Но в релизе все будет совсем по-другому.

Подводя итог: если вы специально не использовали scoped_try_lock (который на самом деле является внутренним вспомогательным классом afaik), вы, вероятно, намеревались использовать scoped_lock.

...