boost::mutex Release VS Debug Build

Question

I am bulding a PCL based application, for which use the default PCL grabber code for velodyne which can seen here.

When i build my application in Debug mode it's working as per the expectations, but in Release build, clouds are etting skipped and i loose one or two clouds. I narrowed down to the fact that there is some issue with the mutex which i have no experience with.

// 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;
};

this is the call back for receiving my cloud and the below part is the one in main

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

I couldn't figure out why there is difference in release vs debug. Any suggestions? I use Visual Studio 2017 and PCL 1.8.1.

score 0 · Answer 1 · edited May 02 '18 at 14:36

Have a look at your second code snippet, "the part in main":

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

confuses me here. try_lock will try to lock the mutex. It will fail to lock the mutex and continue execution, if the mutex is currently in use. The block after the mutex may or may not be protected by the mutex.

Is that really what you want to do? Did you check the status of the lock?

Or did you intend to use

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

That will block the threads execution until it can access the mutex. The block after this statement will always be protected by the mutex.

With try_lock what happens is that if it cannot lock the mutex, execution will continue without the lock. You are responsible for handling this case. If you don't, the mutex will be completely ineffective and you will have race conditions, unsafe concurrent access and other problems.

This could also be the reason why your program behaves differently in release than in debug. In release certain parts of the program run much faster, so the timing behaviour is completely different. It could be that in Debug the timing is such that there is never a concurrent access to the data structure the mutex is meant to protect. But in release this will be completely different.

To sum things up: Unless you intentionally used scoped_try_lock (which is actually an internal helper class afaik) you probably meant to use scoped_lock.

Kirschoff Thank you.. I even tried with scoped_lock, the behaviour is same as with scoped_try_lock. The behaviour is not reproducable too. THe cloud skipped is different all the time — Lakshman ram, Apr 30 '18 at 08:43

boost::mutex Release VS Debug Build

1 Answers1