>> > 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