Fdzfgy

Does is make sense to do something like putting a std::lock_guard in an extra scope so that the locking period is as short as possible?

Pseudo code:

// all used variables beside the lock_guard are created and initialized somewhere else

...// do something



{ // open new scope

    std::lock_guard<std::mutex> lock(mut);

    shared_var = newValue;  

} // close the scope



... // do some other stuff (that might take longer)

Are there more advantages besides having a short lock duration?

What might be negative side effects?

Yes, it certainly makes sense to limit the scope of lock guards to be as short as possible, but not shorter.

The longer you hold a lock, the more likely it is that a thread will block waiting for that lock, which impacts performance as is thus usually considered a bad thing.

However, you must make sure that the program is still correct and that the lock is held at all times when it must be, i.e. when the shared resource protected by the lock is accessed or modified.

There may be one more point to consider (I do not have enough practical experience here to speak with certainty). Locking/releasing a mutex can potentially be an operation with nontrivial performance costs itself. Therefore, it may turn out that keeping a lock for a slightly longer period instead of unlocking & re-locking it several times in the course of one operation can actually improve overall performace. This is something which profiling could show you.

There might be a disadvantage: you cannot protect initializations this way. For example:

{

    std::lock_guard<std::mutex> lock(mut);

    Some_resource var{shared_var};

} // woops! var is lost

You have to use assignment like this:

Some_resource var;

{

    std::lock_guard<std::mutex> lock(mut);

    var = shared_Var;

}

Which can be not as good, you know, since for some types, dummy initialization (I intentionally avoided the term "default initialization") and then assignment is less efficient than directly initialization. (I intentionally avoided the term "direct initialization") Furthermore, in some situations, you cannot change the variable after initialization. (e.g. const ones)

@P i pointed out this solution:

// use an immediately-invoked temporary lambda

Some_resource var {

    [&]() {

        std::lock_guard<std::mutex> lock(mut);

        return shared_var;

    } () // parentheses for invoke

};

This way, with return value optimization, which is implemented well and properly by almost all popular modern compilers, and which is mandated as of C++17, you can do exactly what is expected.

Yes, it makes sense.

There are no other advantages, and there are no side-effects (it is a good way to write it).

An even better way, is to extract it into a private member function (if you have an operation that is synchronized this way, you might as well give the operation its own name):

{

    // all used variables beside the lock_guard are created and initialized somewhere else

    ...// do something



    set_var(new_value);



    ... // do some other stuff (that might take longer)

}



void your_class::set_value(int new_value)

{

    std::lock_guard<std::mutex> lock(mut);

    shared_var = new_value;

}