It is good to know that both std::lock and std::scoped_lock are using a deadlock avoidance algorithm and the order of passed mutexes is irrelevant.
Am I right to assume that in case of many mutexes lock/scoped_lock does not provide a way to have fine grained mutex control? They all will be released in the same time, correct?
That's great that compiler helps avoid mistakes.
I believe ordering locks seems to be simpler in C++ https://en.cppreference.com/w/cpp/thread/scoped_lock
It is good to know that both std::lock and std::scoped_lock are using a deadlock avoidance algorithm and the order of passed mutexes is irrelevant.
Am I right to assume that in case of many mutexes lock/scoped_lock does not provide a way to have fine grained mutex control? They all will be released in the same time, correct?
Lock/scoped_lock holds mutexes in the constructor and releases the mutexes in the destructor.
Do you want to release only some of the mutexes while keeping the rest locked?
Could you help me understand use case in which you want to do that?
That's right, I want to allow some of the mutexes to be released as soon as possible
I see, then I'd suggest using unique_lock + lock. See the example: https://godbolt.org/z/97d7oq8Wz
Look at 27 line.
Thanks a lot Vadim, I learned something new today!