I have a question concerning the use of boost::lock_guard
(or similar scoped locks) and using variables that should be protected by the lock in a return
statement.
How is the order of destroying local objects and copying the return value? How does return value optimization affect this?
Example:
Data Class::GetData()
{
boost::lock_guard<boost::mutex> lock(this->mMutex);
return this->mData;
}
Would this be correct (if mData is the variable protected by mMutex)? Or would I have to use a local scope and a temporary like shown in the example below:
Data Class::GetData()
{
Data ret;
{
boost::lock_guard<boost::mutex> lock(this->mMutex);
ret = this->mData;
}
return ret;
}
The point of lock_guard is just to make locking and unlocking the mutex easier for you. For example, if you manually lock / unlock , but your function throws an exception somewhere in the middle, it will never reach the unlock statement.
The class lock_guard is a mutex wrapper that provides a convenient RAII-style mechanism for owning a mutex for the duration of a scoped block. When a lock_guard object is created, it attempts to take ownership of the mutex it is given.
Just a straight return as in your first example is correct. The return value is constructed before the local variables are destroyed, and thus before the lock is released.
How is the order of destroying local objects and copying the return value?
Generally, stack objects are destroyed in reverse order of creation. As previously stated, both approaches you specify will provide the desired behavior.
How does return value optimization affect this?
RVO should not be a concern here - all this does is construct the output object directly into the stack frame buffer - avoiding the overhead of creating a named temporary object (as in your 2nd example above). This is done before local destructors are invoked.
You're best off using the code from example 1 above.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With