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