Is unlocking a lock_guard manually undefined/bad design?

Question

I've got code thats something like this:

do {
    lock_guard<mutex> lck(globalMtx);
    auto itr = someMap.end();
    for (/*conditions*/){
        //do stuff with itr and someMap
        // if a certain condition is met, we exit function with a return
        // globalMtx needs to be unlocked at that time
    }
    if (itr == someMap.end()){
        // I need to unlock the globalMtx here
        globalMtx.unlock()
        // A command is sent to modify someMap before we try again
        this_thread::sleep_for( chrono::seconds( 5 ) );
    } else {
        break;
    }
} while (true);

As you can see in the if scope, I need to unlock the globalMtx so that I can modify "someMap" before going through it again. I've read in many threads/forums/whatever that manually locking a mutex using mutex.lock()/unlock() is a bad idea and typically never done anymore with c++11 or above.

So what can I do in this case to control the mutex as I need, while still preventing any case where leaving the scope keeps the mutex locked?

Answer 1

No, you should not call std::mutex::unlock() directly in this case, as std::lock_guard destructor would call std::mutex::unlock() again and that would lead to UB. You can use std::unique_lock instead, which is not lightweight as std::lock_guard but allows you to call unlock() on it:

std::unique_lock<mutex> lck(globalMtx);
...
lck.unlock(); // lck object is aware that globalMtx is released and would do nothing in it's dtor after this