As others have pointed out, it already exists in the standard in a symmetric form and is called recursive_mutex.     For a reasoning (beyond performance), why you should try to avoid the need of recursive mutexes in your program design, see this link with an example bug in the file system:   https://www.reddit.com/r/programming/comments/qrju5/comment/c3zyuk2/   During the lock your data structures are in an invalid transition state. That is, why you are using a lock. Your outer interface has as precondition the valid state of the data structures.   To make double locks work you have to introduce the notion of half-valid data structures; or you internally call your functions only in a certain implicitly presumedly safe way, which depends on their implementation.   Or you are not clearly separating between an outside interface and internal helper functions.       -----Ursprüngliche Nachricht----- Von:anshul mittal via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 09.05.2024 08:09 Betreff:Re: [std-proposals] Std-Proposals Digest, Vol 62, Issue 15 An:std-proposals_at_[hidden]; CC:anshul mittal <anshulmttl_at_[hidden]>; 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] <mailto:std-proposals-request_at_[hidden]> > wrote: Send Std-Proposals mailing list submissions to         std-proposals_at_[hidden] <mailto: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] <mailto:std-proposals-request_at_[hidden]> You can reach the person managing the list at         std-proposals-owner_at_[hidden] <mailto: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] <mailto:anshulmttl_at_[hidden]> > To: std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> Subject: Re: [std-proposals] Proposal for extension std::mutex in ISO         C++ Message-ID:         <CAGg_F+LDywQpR-T0bSS0T4jxgAi9iYX6yRFDCeTBWjHADdLCXw_at_[hidden] <mailto:CAGg_F%2BLDywQpR-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] <mailto: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] <mailto:anshulmttl_at_[hidden]> > To: std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> Subject: Re: [std-proposals] Std-Proposals Digest, Vol 62, Issue 14 Message-ID:         <CAGg_F++YNgcbL+t85MXeeK2zwrq0LBo6rn+r8TJiRObuGmBZKg_at_[hidden] <mailto:CAGg_F%2B%2BYNgcbL%2Bt85MXeeK2zwrq0LBo6rn%2Br8TJiRObuGmBZKg_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] <mailto:std-proposals-request_at_[hidden]> > wrote: > Send Std-Proposals mailing list submissions to >         std-proposals_at_[hidden] <mailto: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] <mailto:std-proposals-request_at_[hidden]> > > You can reach the person managing the list at >         std-proposals-owner_at_[hidden] <mailto: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] <mailto:wangjufan_at_[hidden]> > > To: "C++" <std-proposals_at_[hidden] <mailto: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] <mailto: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] <mailto: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] <mailto: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] <mailto:anshulmttl_at_[hidden]> > > To: std-proposals_at_[hidden] <mailto: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] <mailto:DsGvBrEK%2BPt1C7WCg_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] <mailto:thiago_at_[hidden]> > > To: std-proposals_at_[hidden] <mailto: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 <http://macieira.info> - thiago (AT) kde.org <http://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] <mailto:giuseppe.dangelo_at_[hidden]> > > To: std-proposals_at_[hidden] <mailto: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] <mailto: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] <mailto: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] <mailto: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 -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals