There is merit in being able to choose the mutex though.

There are mutexes with deadlock detection instrumentation. Others have
specialized optimizations for certain workloads.
Others would expose shared/unique locking interfaces.

I say this because I work in an application that makes use of all those
types.

It also allows for recursive_mutex, and we do use it, but we are not proud
of it :)

Breno G.


Em qua., 28 de jun. de 2023 20:56, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> escreveu:

> On Wed, Jun 28, 2023 at 7:13 PM Frederick Virchanza Gotham via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
> >
> > On Thu, Jun 29, 2023 at 12:05 AM Ville Voutilainen via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> > >>
> > > > Indeed. This is boost::synchronized_value<T>.
> > >
> > > There's also a synchronized_value in
> > > https://open-std.org/JTC1/SC22/WG21/docs/papers/2023/n4953.pdf
> > > I thought Jonathan mentioned that earlier?
> >
> >
> > It turns out that the GNU compiler g++ version 13 already has this
> > under std::experimental.
> >
> > Looking through the implementation of boost:synchronized_value, it
> > looks like it uses a regular mutex. My own implementation of my own
> > class uses a recursive mutex so that you can do stuff like:
> >
> > void Func2(void)
> > {
> > g_obj->push_back(78);
> > }
> >
> > void Func(void)
> > {
> > auto mylock = g_obj.Reserve();
> > mylock->push_back(73);
> > mylock->push_back(71);
> > Func2(); // This would cause thread-lock if the mutex weren't a
> > recursive_mutex
> > mylock->push_back(79);
> > }
> >
> > I think a recursive_mutex is better here.
>
> Code that does things like that should be broken.
>
> The first principle of good thread-safe code is to not share stuff
> across threads. If something must be shared across threads, it should
> be designed to be shared for that particular purpose. If your use of
> shared objects is so unstructured that you can't even stop *your own
> thread* from double-locking such an object, then it seems pretty
> unlikely you're writing good code.
>
> We shouldn't pretend code is "thread-safe" just because you use a
> mutex-based interface for some shared object.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>