Thanks Jason for your comments. I missed the underlying std::lock
capabilities.

I would rather propose a new lock that takes runtime defined mutexes and a
corresponding RAII wrapper for it.

Regards
Bharath

On Tue, Feb 7, 2023 at 1:17 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
From
Bharath S