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