recursive_mutex does not create the deadlock i mentioned in my email. I
will use recursive_mutex for my project.

On Thu, May 9, 2024 at 12:00 PM <std-proposals-request_at_[hidden]>
wrote:

> Send Std-Proposals mailing list submissions to
> std-proposals_at_[hidden]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> or, via email, send a message with subject or body 'help' to
> std-proposals-request_at_[hidden]
>
> You can reach the person managing the list at
> std-proposals-owner_at_[hidden]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Std-Proposals digest..."
>
>
> Today's Topics:
>
> 1. Re: Std-Proposals Digest, Vol 62, Issue 17 (anshul mittal)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 9 May 2024 12:00:24 +0530
> From: anshul mittal <anshulmttl_at_[hidden]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] Std-Proposals Digest, Vol 62, Issue 17
> Message-ID:
> <CAGg_F++EsfPATvVURBDcAxcbypsxnUwyccNLf=Q25OBn-=
> HthQ_at_[hidden]>
> Content-Type: text/plain; charset="utf-8"
>
> >> > 4) Checking the thread id isn't sufficient, as this exposes you to ABA
> >> > problems. A thread can lock the mutex and quit, and then the same id
> may
> >> > get recycled by a new thread, which will then successfully lock the
> >> > already locked mutex. That makes no sense.
> You dont use Thread ID. You use something you know in C++.
>
> >> > 5) If you just want a deadlock debugging feature for mutexes, then you
> >> > can already build what you want around std::mutex. Or, just use TSAN
> >> > and/or a mutex that offers this feature out of the box, like
> It doesnt offer what i said.
>
> I developed this technology for my project and i am using it.
>
> On Thu, May 9, 2024 at 11:52?AM <std-proposals-request_at_[hidden]>
> wrote:
>
> > Send Std-Proposals mailing list submissions to
> > std-proposals_at_[hidden]
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> > or, via email, send a message with subject or body 'help' to
> > std-proposals-request_at_[hidden]
> >
> > You can reach the person managing the list at
> > std-proposals-owner_at_[hidden]
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Std-Proposals digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: Std-Proposals Digest, Vol 62, Issue 15 (anshul mittal)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Thu, 9 May 2024 11:52:18 +0530
> > From: anshul mittal <anshulmttl_at_[hidden]>
> > To: std-proposals_at_[hidden]
> > Subject: Re: [std-proposals] Std-Proposals Digest, Vol 62, Issue 15
> > Message-ID:
> > <
> > CAGg_F+KX+k+Yy6POH27KXAL3VdH7AptOcR57bPAbvsD8RUiA6A_at_[hidden]>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Create new mutex for C++ 21.
> >
> > On Thu, May 9, 2024 at 11:39?AM anshul mittal <anshulmttl_at_[hidden]>
> > wrote:
> >
> > > Use a new class for this.
> > >
> > > > 1) This goes against the general C++ principle of "don't pay for what
> > > > you don't use". A program that doesn't lock the same mutex twice in
> the
> > > > same thread doesn't need this facility. For such a program, checking
> > the
> > > > current thread id at every lock is just overhead.
> > > >
> > > > 2) All programs that are currently using mutex correctly (i.e.: all
> the
> > > > existing *correct* programs) therefore don't need any of the sorts.
> The
> > > > corollary is that such a feature is a pessimization for all existing
> > > > code. That doesn't exactly sell the idea, to put it mildly.
> > > >
> > > > 3) If you need a recursive mutex, there's already a dedicated
> facility
> > > > for that. But a recursive mutex seems to be different from what
> you're
> > > > proposing: a recursive mutex requires the numbers of calls to lock()
> > and
> > > > unlock() to match, while yours doesn't.
> > > >
> > > > 4) Checking the thread id isn't sufficient, as this exposes you to
> ABA
> > > > problems. A thread can lock the mutex and quit, and then the same id
> > may
> > > > get recycled by a new thread, which will then successfully lock the
> > > > already locked mutex. That makes no sense.
> > > >
> > > > 5) If you just want a deadlock debugging feature for mutexes, then
> you
> > > > can already build what you want around std::mutex. Or, just use TSAN
> > > > and/or a mutex that offers this feature out of the box, like
> > absl::Mutex.
> > >
> > > On Thu, May 9, 2024 at 11:35?AM <
> std-proposals-request_at_[hidden]>
> > > wrote:
> > >
> > >> Send Std-Proposals mailing list submissions to
> > >> std-proposals_at_[hidden]
> > >>
> > >> To subscribe or unsubscribe via the World Wide Web, visit
> > >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> > >> or, via email, send a message with subject or body 'help' to
> > >> std-proposals-request_at_[hidden]
> > >>
> > >> You can reach the person managing the list at
> > >> std-proposals-owner_at_[hidden]
> > >>
> > >> When replying, please edit your Subject line so it is more specific
> > >> than "Re: Contents of Std-Proposals digest..."
> > >>
> > >>
> > >> Today's Topics:
> > >>
> > >> 1. Re: Proposal for extension std::mutex in ISO C++ (anshul mittal)
> > >> 2. Re: Std-Proposals Digest, Vol 62, Issue 14 (anshul mittal)
> > >>
> > >>
> > >> ----------------------------------------------------------------------
> > >>
> > >> Message: 1
> > >> Date: Thu, 9 May 2024 11:23:20 +0530
> > >> From: anshul mittal <anshulmttl_at_[hidden]>
> > >> To: std-proposals_at_[hidden]
> > >> Subject: Re: [std-proposals] Proposal for extension std::mutex in ISO
> > >> C++
> > >> Message-ID:
> > >> <
> > >> CAGg_F+LDywQpR-T0bSS0T4jxgAi9iYX6yRFDCeTBWjHADdLCXw_at_[hidden]>
> > >> Content-Type: text/plain; charset="utf-8"
> > >>
> > >> Link to proposal : https://www.soft.amsbctech.com/page-3/
> > >>
> > >> Press the download button on website.
> > >>
> > >> On Thu, May 9, 2024 at 10:14?AM anshul mittal <anshulmttl_at_[hidden]>
> > >> wrote:
> > >>
> > >> > I am Anshul Mittal building webserver using C++. I have found a new
> > >> > solution to a problem.
> > >> >
> > >> > When a single thread tries locking on the same mutex std::mutex it
> > >> creates
> > >> > a deadlock. This situation can arise in some projects and it arose
> for
> > >> me.
> > >> >
> > >> > I am sending this proposal to update the specification to
> incorporate
> > >> this
> > >> > new technology.
> > >> >
> > >> > The std::mutex should not allow locking if the same thread is
> > requesting
> > >> > the lock on same mutex.
> > >> >
> > >> > You can get thread id using std::this_thread::get_id().
> > >> >
> > >> > Eg.
> > >> > Current situation :
> > >> > mutex mut;
> > >> > mut.lock();
> > >> > mut.lock();
> > >> > This creates a deadlock.
> > >> >
> > >> > By putting thread id check the deadlock is prevented. I call this
> > >> > SampleMutex.
> > >> > SampleMutex mut;
> > >> > mut.lock();
> > >> > mut.lock(); // This lock should not happen and no deadlock created.
> > >> >
> > >> >
> > >>
> > >> --
> > >> Anshul Mittal
> > >> Graduate Engineer Trainee
> > >> TVM signalling and transportation Systems
> > >> -------------- next part --------------
> > >> HTML attachment scrubbed and removed
> > >>
> > >> ------------------------------
> > >>
> > >> Message: 2
> > >> Date: Thu, 9 May 2024 11:35:23 +0530
> > >> From: anshul mittal <anshulmttl_at_[hidden]>
> > >> To: std-proposals_at_[hidden]
> > >> Subject: Re: [std-proposals] Std-Proposals Digest, Vol 62, Issue 14
> > >> Message-ID:
> > >> <
> > >> CAGg_F++YNgcbL+t85MXeeK2zwrq0LBo6rn+r8TJiRObuGmBZKg_at_[hidden]>
> > >> Content-Type: text/plain; charset="utf-8"
> > >>
> > >> That means it's a bug in your code. You should fix your code. A mutex
> > >> silently
> > >> not locking and reporting success is a horrible idea because the
> number
> > of
> > >> unlocks will now be unpaired.
> > >> Answer : That is some technology in C++ i dont know because i dont
> have
> > >> C++
> > >> code. This proposal is to add new standard to C++.
> > >>
> > >> Maybe you want to use std::recursive_mutex and argue with your code
> > >> reviewers
> > >> that this is the correct solution for your problem. In many projects I
> > >> know
> > >> of
> > >> (but not all), use of a recursive mutex is an automatic rejection.
> > >> Answer : I have solution to my problem. I am asking to add this as a
> > >> standard because same thread should not lock on mutex multiple times.
> > >>
> > >> On Thu, May 9, 2024 at 11:21?AM <
> std-proposals-request_at_[hidden]
> > >
> > >> wrote:
> > >>
> > >> > Send Std-Proposals mailing list submissions to
> > >> > std-proposals_at_[hidden]
> > >> >
> > >> > To subscribe or unsubscribe via the World Wide Web, visit
> > >> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> > >> > or, via email, send a message with subject or body 'help' to
> > >> > std-proposals-request_at_[hidden]
> > >> >
> > >> > You can reach the person managing the list at
> > >> > std-proposals-owner_at_[hidden]
> > >> >
> > >> > When replying, please edit your Subject line so it is more specific
> > >> > than "Re: Contents of Std-Proposals digest..."
> > >> >
> > >> >
> > >> > Today's Topics:
> > >> >
> > >> > 1. Derived object by reference to single parameter delegated
> > >> > templated constructors (David wang)
> > >> > 2. Proposal for extension std::mutex in ISO C++ (anshul mittal)
> > >> > 3. Re: Proposal for extension std::mutex in ISO C++ (Thiago
> > Macieira)
> > >> > 4. Re: Proposal for extension std::mutex in ISO C++
> > >> > (Giuseppe D'Angelo)
> > >> >
> > >> >
> > >> >
> ----------------------------------------------------------------------
> > >> >
> > >> > Message: 1
> > >> > Date: Thu, 9 May 2024 10:09:00 +0800
> > >> > From: David wang <wangjufan_at_[hidden]>
> > >> > To: "C++" <std-proposals_at_[hidden]>
> > >> > Subject: [std-proposals] Derived object by reference to single
> > >> > parameter delegated templated constructors
> > >> > Message-ID:
> > >> > <CAF7c4zmZXSimYLpxGKhrz0JJWe=
> > >> > UY7-xL2BJ4rX_LrGh8sNkZQ_at_[hidden]>
> > >> > Content-Type: text/plain; charset="utf-8"
> > >> >
> > >> > On Tue, May 7, 2024 at 3:46?AM Arthur OrDwyer via Std-Proposals
> > >> > <std-proposals_at_[hidden]> wrote:
> > >> >
> > >> > >This code is buggy. But it also violates the Rule of Zero: you
> wrote
> > >> code
> > >> > >*manually*, and you got it *wrong*, so naturally it's also going to
> > do
> > >> > >the wrong thing.
> > >> >
> > >> > Think about it, the code you wrote class by class is absolutely
> > >> correct, I
> > >> > mean not breaking any rules. But some code sequences are wrong,
> which
> > >> means
> > >> > I have to focus on combinations of codes, which is very bad.
> > >> >
> > >> > >And it leads us to a specific workaround in this case. If we really
> > >> must
> > >> > >take control of `Derived`'s value semantics ? if we can't delegate
> > >> them to
> > >> > >some other "resource-management type" ? then we must take the
> > >> > >responsibility for ensuring that the correct code is run for each
> > thing
> > >> > >that we manually do.
> > >> >
> > >> > We can do it automatically for the user.
> > >> > Before passing a derived object to the single parameter templated
> > >> > constructor, the copying process for the derived object is currently
> > >> > underway. *The single parameter Delegated C++ constructor's copy
> > >> semantics
> > >> > simply copy the portion declared in the derived object's base class.
> > The
> > >> > portion declared in the derived class do not need to be copied or
> > >> > constructed again. * The language's syntax is designed to express
> and
> > >> > convey the intended meaning or semantics of the code. The rules
> should
> > >> > strike a balance between syntax and semantics to better serve the
> > >> intended
> > >> > meaning of the code. PR87310
> > >> > <https://github.com/llvm/llvm-project/pull/87310>
> > >> >
> > >> > ==============
> > >> >
> > >> > On TWed, 8 May 2024 13:25:41 -0400 Jason McKesson via Std-Proposals
> > >> > <std-proposals_at_[hidden]> wrote:
> > >> >
> > >> > >I meant that `base(that)` should be `base(std::ref(that))`, and
> > >> > >`base`'s constructor should be changed accordingly.
> > >> >
> > >> > `base(std::ref(that))` solves the problem via introducing another
> > level
> > >> of
> > >> > abstraction.
> > >> > And `std::ref` still can be instantiated with `T`(for example struct
> > >> > derived) as a reference type.
> > >> >
> > >> > *struct* base {
> > >> >
> > >> > *public* : base() {}
> > >> >
> > >> > *template* <*typename* T> base(T x) {}
> > >> >
> > >> > };
> > >> >
> > >> > *struct* derived : *public* base {
> > >> >
> > >> > *public*: derived() {}
> > >> >
> > >> > derived(derived& that): base(std::ref(that)) {}
> > >> >
> > >> > };
> > >> >
> > >> > *int* main() {
> > >> >
> > >> > derived d1;
> > >> >
> > >> > derived d2 = d1;
> > >> >
> > >> > *return* 0;
> > >> >
> > >> > }
> > >> > -------------- next part --------------
> > >> > HTML attachment scrubbed and removed
> > >> >
> > >> > ------------------------------
> > >> >
> > >> > Message: 2
> > >> > Date: Thu, 9 May 2024 10:14:20 +0530
> > >> > From: anshul mittal <anshulmttl_at_[hidden]>
> > >> > To: std-proposals_at_[hidden]
> > >> > Subject: [std-proposals] Proposal for extension std::mutex in ISO
> C++
> > >> > Message-ID:
> > >> > <CAGg_F+L9JgVZeo9Vb=nd22_TMk=KVevR=
> > >> > DsGvBrEK+Pt1C7WCg_at_[hidden]>
> > >> > Content-Type: text/plain; charset="utf-8"
> > >> >
> > >> > I am Anshul Mittal building webserver using C++. I have found a new
> > >> > solution to a problem.
> > >> >
> > >> > When a single thread tries locking on the same mutex std::mutex it
> > >> creates
> > >> > a deadlock. This situation can arise in some projects and it arose
> for
> > >> me.
> > >> >
> > >> > I am sending this proposal to update the specification to
> incorporate
> > >> this
> > >> > new technology.
> > >> >
> > >> > The std::mutex should not allow locking if the same thread is
> > requesting
> > >> > the lock on same mutex.
> > >> >
> > >> > You can get thread id using std::this_thread::get_id().
> > >> >
> > >> > Eg.
> > >> > Current situation :
> > >> > mutex mut;
> > >> > mut.lock();
> > >> > mut.lock();
> > >> > This creates a deadlock.
> > >> >
> > >> > By putting thread id check the deadlock is prevented. I call this
> > >> > SampleMutex.
> > >> > SampleMutex mut;
> > >> > mut.lock();
> > >> > mut.lock(); // This lock should not happen and no deadlock created.
> > >> > -------------- next part --------------
> > >> > HTML attachment scrubbed and removed
> > >> >
> > >> > ------------------------------
> > >> >
> > >> > Message: 3
> > >> > Date: Wed, 08 May 2024 22:38:34 -0700
> > >> > From: Thiago Macieira <thiago_at_[hidden]>
> > >> > To: std-proposals_at_[hidden]
> > >> > Subject: Re: [std-proposals] Proposal for extension std::mutex in
> ISO
> > >> > C++
> > >> > Message-ID: <2050354.Jadu78ljVU_at_[hidden]>
> > >> > Content-Type: text/plain; charset="utf-8"
> > >> >
> > >> > On Wednesday 8 May 2024 21:44:20 GMT-7 anshul mittal via
> Std-Proposals
> > >> > wrote:
> > >> > > When a single thread tries locking on the same mutex std::mutex it
> > >> > creates
> > >> > > a deadlock. This situation can arise in some projects and it arose
> > for
> > >> > me.
> > >> >
> > >> > That means it's a bug in your code. You should fix your code. A
> mutex
> > >> > silently
> > >> > not locking and reporting success is a horrible idea because the
> > number
> > >> of
> > >> > unlocks will now be unpaired.
> > >> >
> > >> > Maybe you want to use std::recursive_mutex and argue with your code
> > >> > reviewers
> > >> > that this is the correct solution for your problem. In many
> projects I
> > >> > know of
> > >> > (but not all), use of a recursive mutex is an automatic rejection.
> > >> >
> > >> > --
> > >> > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> > >> > Principal Engineer - Intel DCAI Cloud Engineering
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > ------------------------------
> > >> >
> > >> > Message: 4
> > >> > Date: Thu, 9 May 2024 07:51:29 +0200
> > >> > From: Giuseppe D'Angelo <giuseppe.dangelo_at_[hidden]>
> > >> > To: std-proposals_at_[hidden]
> > >> > Subject: Re: [std-proposals] Proposal for extension std::mutex in
> ISO
> > >> > C++
> > >> > Message-ID: <dc38825d-f2e0-46cf-8a2e-620dd0bba3fb_at_[hidden]>
> > >> > Content-Type: text/plain; charset="utf-8"; Format="flowed"
> > >> >
> > >> > Hello,
> > >> >
> > >> > Il 09/05/24 06:44, anshul mittal via Std-Proposals ha scritto:
> > >> > > The std::mutex should not allow locking if the same thread is
> > >> requesting
> > >> > > the lock on same mutex.
> > >> > >
> > >> > > You can get thread id using std::this_thread::get_id().
> > >> > >
> > >> > > Eg.
> > >> > > Current situation :
> > >> > > mutex mut;
> > >> > > mut.lock();
> > >> > > mut.lock();
> > >> > > This creates a deadlock.
> > >> > >
> > >> > > By putting thread id check the deadlock is prevented. I call?this
> > >> > > SampleMutex.
> > >> > > SampleMutex mut;
> > >> > > mut.lock();
> > >> > > mut.lock(); // This lock should not happen and no deadlock
> created.
> > >> >
> > >> > There's multiple problems with this idea.
> > >> >
> > >> > 1) This goes against the general C++ principle of "don't pay for
> what
> > >> > you don't use". A program that doesn't lock the same mutex twice in
> > the
> > >> > same thread doesn't need this facility. For such a program, checking
> > the
> > >> > current thread id at every lock is just overhead.
> > >> >
> > >> > 2) All programs that are currently using mutex correctly (i.e.: all
> > the
> > >> > existing *correct* programs) therefore don't need any of the sorts.
> > The
> > >> > corollary is that such a feature is a pessimization for all existing
> > >> > code. That doesn't exactly sell the idea, to put it mildly.
> > >> >
> > >> > 3) If you need a recursive mutex, there's already a dedicated
> facility
> > >> > for that. But a recursive mutex seems to be different from what
> you're
> > >> > proposing: a recursive mutex requires the numbers of calls to lock()
> > and
> > >> > unlock() to match, while yours doesn't.
> > >> >
> > >> > 4) Checking the thread id isn't sufficient, as this exposes you to
> ABA
> > >> > problems. A thread can lock the mutex and quit, and then the same id
> > may
> > >> > get recycled by a new thread, which will then successfully lock the
> > >> > already locked mutex. That makes no sense.
> > >> >
> > >> > 5) If you just want a deadlock debugging feature for mutexes, then
> you
> > >> > can already build what you want around std::mutex. Or, just use TSAN
> > >> > and/or a mutex that offers this feature out of the box, like
> > >> absl::Mutex.
> > >> >
> > >> >
> > >> > My 2 c,
> > >> >
> > >> > --
> > >> > Giuseppe D'Angelo
> > >> >
> > >> > -------------- next part --------------
> > >> > A non-text attachment was scrubbed...
> > >> > Name: smime.p7s
> > >> > Type: application/pkcs7-signature
> > >> > Size: 4244 bytes
> > >> > Desc: Firma crittografica S/MIME
> > >> > URL: <
> > >> >
> > >>
> >
> https://lists.isocpp.org/std-proposals/attachments/20240509/d6c0cfb9/attachment.bin
> > >> > >
> > >> >
> > >> > ------------------------------
> > >> >
> > >> > Subject: Digest Footer
> > >> >
> > >> > Std-Proposals mailing list
> > >> > Std-Proposals_at_[hidden]
> > >> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> > >> >
> > >> >
> > >> > ------------------------------
> > >> >
> > >> > End of Std-Proposals Digest, Vol 62, Issue 14
> > >> > *********************************************
> > >> >
> > >>
> > >>
> > >> --
> > >> Anshul Mittal
> > >> Graduate Engineer Trainee
> > >> TVM signalling and transportation Systems
> > >> -------------- next part --------------
> > >> HTML attachment scrubbed and removed
> > >>
> > >> ------------------------------
> > >>
> > >> Subject: Digest Footer
> > >>
> > >> Std-Proposals mailing list
> > >> Std-Proposals_at_[hidden]
> > >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> > >>
> > >>
> > >> ------------------------------
> > >>
> > >> End of Std-Proposals Digest, Vol 62, Issue 15
> > >> *********************************************
> > >>
> > >
> > >
> > > --
> > > Anshul Mittal
> > > Graduate Engineer Trainee
> > > TVM signalling and transportation Systems
> > >
> >
> >
> > --
> > Anshul Mittal
> > Graduate Engineer Trainee
> > TVM signalling and transportation Systems
> > -------------- next part --------------
> > HTML attachment scrubbed and removed
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> >
> >
> > ------------------------------
> >
> > End of Std-Proposals Digest, Vol 62, Issue 17
> > *********************************************
> >
>
>
> --
> Anshul Mittal
> Graduate Engineer Trainee
> TVM signalling and transportation Systems
> -------------- next part --------------
> HTML attachment scrubbed and removed
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Avoiding mutex lock on same thread.pdf
> Type: application/pdf
> Size: 54435 bytes
> Desc: not available
> URL: <
> https://lists.isocpp.org/std-proposals/attachments/20240509/09cf5268/attachment.pdf
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> ------------------------------
>
> End of Std-Proposals Digest, Vol 62, Issue 19
> *********************************************
>

-- 
Anshul Mittal
Graduate Engineer Trainee
TVM signalling and transportation Systems