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