C++ Logo

std-proposals

Advanced search

Re: [std-proposals] scoped_lock to support variable number of locks determined during runtime

From: Bharath S <bharath.sekarp_at_[hidden]>
Date: Tue, 7 Feb 2023 13:00:16 -0500
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?

Regards
Bharath

On Mon, Feb 6, 2023, 11:42 p.m. Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> See also (same request, no standard solution):
>
>
> https://stackoverflow.com/questions/69366623/stdscoped-lock-vector-of-mutexes
>
>
> Why not create a custom mutex type, which delegates to the other mutices?
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Bharath S via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Di 07.02.2023 05:16
> *Betreff:* [std-proposals] scoped_lock to support variable number of
> locks determined during runtime
> *An:* std-proposals_at_[hidden];
> *CC:* Bharath S <bharath.sekarp_at_[hidden]>;
> Hello everyone,
>
> std::scoped_lock taking in just a variadic mutexes is restrictive.
> In one such scenario where there are jobs that are scheduled. These jobs
> has their own set of tasks to achieve. These task can work on a set of
> configurable inputs and outputs. The outputs of one of the task can be an
> input of another task under a different job that is scheduled. Since these
> are configurable, the mutexes creation is done during the process init and
> job scheduling. Hence there is no way to use scoped_lock which is an
> excellent addition to lock all or nothing mutexes that avoids deadlock.
> How about an RAII for scoped_lock which takes a std container of mutexes
> (or unique ptrs of mutexes). ? Is this a valid proposal? Am I missing
> something that is already there and easy to use like scoped lock?
>
> Regards
> Bharath
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

Received on 2023-02-07 18:00:27