On Tue, Feb 7, 2023 at 1:00 PM Bharath S via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Yes. When I wanted to solution I saw this thread too. But as you have mentioned I couldn't get any good solution that exists. Thanks for including the link.
>
> Can you please elaborate on the custom mutex solution.?
>
> As I understand, are you suggesting a mutex that governs the locking of these runtime mutexes? This would mean that some of the mutually exclusive threads ( meaning threads which doesn't depend on the inputs or outputs of each other) would also wait on the mutex that governs the critical section to acquire the mutexes, which might not be an optimal solution.
>
> Can't we add to std lib to have scoped_lock accept vector of mutexes? Will it violate any standard?

Well at a fundamental level, you can't change scoped_lock to do that
because its interface doesn't allow it. `scoped_lock` is a variadic
template. It takes a heterogeneous sequence of elements; this means
that each mutex need not be the same mutex. Which also means that the
sequence is defined at compile-time.

What you need is a new type that takes a runtime-defined sequence of
mutexes of the same type. But to do that, you need a version of
`std::lock` that *also* takes a sequence of elements (since
std::lock's deadlock guarantee is the entire reason why you want this,
and `std::lock` also is a variadic template). Boost has one of those,
so it's not unreasonable as a concept.