On 9/26/2023 5:37 AM, Bonita Montero wrote:
> Am 26.09.2023 um 13:23 schrieb Richard Damon:
>
>> But it doesn't NEED to be expected, and doing it in a way that allows
>> for failure when you can do it in a way that can't fail is just being
>> a bad implementation.
>
> The slow path always is backed by a binary semaphore of the kernel.
> You can't create an arbitrary number of that.

Barf! God damn it Bonita! I might have to try to refrain from reading
your posts. PUKE!

On 9/26/2023 8:33 AM, Bonita Montero wrote:
> Am 26.09.2023 um 17:24 schrieb Scott Lurndal:
>
>> No, it is not.   The kernel simply moves the waiter thread to
>> a non-runnable queue in the dispatcher until a call to 'unlock'
>> determines that there is a waiter and tells the kernel to
>> awaken it.
>
> The userspace code must tell the kernel what it its waiting for.
> Mutexes are always a combination of an atomic for the fast path
> and a binary semapohre for the slow path.
>

Word salad that you do not even understand. Sorry buddy.

On 9/26/2023 10:13 AM, Scott Lurndal wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> On 2023-09-26, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 26.09.2023 um 13:42 schrieb Richard Damon:
>>>
>>>> Again, your argument boils down to: Even though there is a way to do
>>>> it without failure, the fact that another, "defective" way exists that
>>>> might generate an error, the Standard should be modified so that
>>>> "defective" method can be used.
>>>
>>> Pthread mutexes can be initialized statically, but then you have the
>>> same kind of delayed inititialization - which may fail.
>>
>> It has already been explained that none of the error codes given in
>> POSIX for the pthread_mutex_lock function have anything to do with
>> resource acquisition.
>
> Although it is fair to point out that POSIX allows additional
> implementation-defined error codes for POSIX interfaces, so long
> as the listed conditions return the listed error codes.
>
> That's not meant to imply that posix mutexes will ever fail, however.

Good point. :^)

On Tuesday, September 26, 2023 at 10:59:06 PM UTC+3, Chris M. Thomasson wrote:
> On 9/26/2023 9:05 AM, Michael S wrote:
> > On Tuesday, September 26, 2023 at 8:53:13 AM UTC+3, Chris M. Thomasson wrote:
> >> On 9/24/2023 10:04 AM, Kaz Kylheku wrote:
> >>> On 2023-09-24, Bonita Montero <Bonita....@gmail.com> wrote:
> >>>> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku:
> >>>>
> >>>>> A possible design is that each *thread* has a wait semaphore.
> >>>>
> >>>> You'd have to register the binary semaphore and register as a waiter in
> >>>> one atomic step. You could do that with a DCAS'd ring, but you coudn't
> >>>> atomically update the link pointers of the other nodes at the same
> >>>> time you update the roots link pointers. And you would have the deallo-
> >>>> cation poblem, i.e. the memory of your object may never be deallocated.
> >>>
> >>> Now you're just throwing together words you don't understand.
> >>>
> >>>> Show me your implementation !
> >>>
> >>> E.g. old LinuxThreads in glibc, circa 2000:
> >>>
> >>> https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe
> >>>
> >>> The low level __pthread_lock and __pthread_unlock functions maintain a
> >>> queue, using a single-word atomic CAS.
> >>>
> >>> There are suspend() and resume() functions for the waiting;
> >>> they are elsewhere.
> >>>
> >>> If you look in restart.h you can see that those operations are defined
> >>> in two different ways, both of which use signals (not a semaphore per
> >>> thread). A suspending thread waits for the arrival of a signal,
> >>> resume is done by sending a signal. That's kind of semaphore-like;
> >>> and POSIX real-time signals can even queue up, like a counting sem.
> >>>
> >>>> It's ridiculous because mutex are a cheap resource. And if such imple-
> >>>> mentation would be possible the standard shouldn't mandate it since
> >>>> not every platform has a DCAS.
> >>>
> >>> Things can be done in ways you havn't thought about.
> >>>
> >>> Atomic operations aren't required to achieve mutual exclusion among
> >>> processors that share memory.
> >>>
> >>> As someone continually insisting on having expertise in concurrency,
> >>> you must be familiar with the research work of Leslie Lamport?
> >>
> >> Iirc, that uses atomic loads, stores and membars. Iirc, it requires a
> >> #StoreLoad barrier on the SPARC. Iirc, it even requires an explicit
> >> membar on the x86. MFENCE, or XCHG which has the lock prefix
> >> automatically asserted. Humm... There is a way to get around that
> >> bastard #StoreLoad membar... It uses an async sync setup. The funny
> >> thing is that Windows has a API that can be used to actually implement
> >> it! Try to think of a so called, remote memory barrier, in a sense:
> >>
> >> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers
> >>
> >> There is a way to use this to get an async mutex that is kind of sort of
> >> akin to a read write mutex. Basically, the mutex is broken down into two
> >> parts. One that represents accesses that _very_ frequently called upon..
> >> The other one is used rather rarely. This is the async nature that can
> >> be exploited in rather interesting ways. I implemented some in the past
> >> with Dmitry Vyukov. Also, this FlushProcessWriteBuffers API can be used
> >> to implement other rather exotic sync schemes. They have very excellent
> >> performance for certain workloads. Actually, there is a way to use it to
> >> get a RCU in userspace and/or hazard pointers without any explicit
> >> #StoreLoad membars.
> >>
> >>
> >
> > I would expect FlushProcessWriteBuffers() to be 2 orders of magnitude
> > slower than #StoreLoad membar. I could be wrong, of course, the function
> > is close to undocumented.
> FlushProcessWriteBuffers() can be used to gain a quiescent state wrt
> memory visibility for some exotic async algorithms, it is called in
> certain places and is RARE. However, on the other hand, having to use a
> #StoreLoad membar on the fast path is not good. Keep in mind that this
> is meant to handle a store followed by a load to another location
> scenario. We need to honor the #StoreLoad relationship for this type of
> setup for these types of algorithms. For instance, hazard pointers
> require a #StoreLoad, however there is a way to eliminate them using
> some special magic wrt RCU...
>
> My friend Joe Seigh created SMR+RCU to gain this. SMR is hazard
> pointers. Now, keep in mind that these are very "specialized" algorithms
> that try to make certain workloads MUCH faster and way more efficient.
> They work for that.
>
> Also, keep in mind that a normal mutex does not require #StoreLoad. Only
> acquire and release:
>
> acquire = #LoadStore | #LoadLoad
> release = #LoadStore | #StoreStore
>
> In SPARC parlance. For instance, an atomic store on x86 automatically
> implies release. Btw, have you ever worked with SPARC in RMO mode? Its
> fun because its so weak.
>

We discussed it already. I don't think that SPARCv9 RMO hardware
ever existed and you failed to convince me otherwise.

As to weakness, I don't think that by specification it is weaker than IPF,
may be not even weaker than POWER. Certainly stronger than Alpha.
But it does not matter since it does not exist.

> I still need to find that old paper called QPI, if I remember correctly.
> It should still be out there. I will try to find it sometime today.
>
> It think is was from Dice wrt a Java VM. David Dice? Damn I cannot
> remember it right now. Sorry. ;^o
>
>
> [...]

On 9/26/2023 1:58 PM, Michael S wrote:
> On Tuesday, September 26, 2023 at 10:59:06 PM UTC+3, Chris M. Thomasson wrote:
>> On 9/26/2023 9:05 AM, Michael S wrote:
>>> On Tuesday, September 26, 2023 at 8:53:13 AM UTC+3, Chris M. Thomasson wrote:
>>>> On 9/24/2023 10:04 AM, Kaz Kylheku wrote:
>>>>> On 2023-09-24, Bonita Montero <Bonita....@gmail.com> wrote:
>>>>>> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku:
>>>>>>
>>>>>>> A possible design is that each *thread* has a wait semaphore.
>>>>>>
>>>>>> You'd have to register the binary semaphore and register as a waiter in
>>>>>> one atomic step. You could do that with a DCAS'd ring, but you coudn't
>>>>>> atomically update the link pointers of the other nodes at the same
>>>>>> time you update the roots link pointers. And you would have the deallo-
>>>>>> cation poblem, i.e. the memory of your object may never be deallocated.
>>>>>
>>>>> Now you're just throwing together words you don't understand.
>>>>>
>>>>>> Show me your implementation !
>>>>>
>>>>> E.g. old LinuxThreads in glibc, circa 2000:
>>>>>
>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe
>>>>>
>>>>> The low level __pthread_lock and __pthread_unlock functions maintain a
>>>>> queue, using a single-word atomic CAS.
>>>>>
>>>>> There are suspend() and resume() functions for the waiting;
>>>>> they are elsewhere.
>>>>>
>>>>> If you look in restart.h you can see that those operations are defined
>>>>> in two different ways, both of which use signals (not a semaphore per
>>>>> thread). A suspending thread waits for the arrival of a signal,
>>>>> resume is done by sending a signal. That's kind of semaphore-like;
>>>>> and POSIX real-time signals can even queue up, like a counting sem.
>>>>>
>>>>>> It's ridiculous because mutex are a cheap resource. And if such imple-
>>>>>> mentation would be possible the standard shouldn't mandate it since
>>>>>> not every platform has a DCAS.
>>>>>
>>>>> Things can be done in ways you havn't thought about.
>>>>>
>>>>> Atomic operations aren't required to achieve mutual exclusion among
>>>>> processors that share memory.
>>>>>
>>>>> As someone continually insisting on having expertise in concurrency,
>>>>> you must be familiar with the research work of Leslie Lamport?
>>>>
>>>> Iirc, that uses atomic loads, stores and membars. Iirc, it requires a
>>>> #StoreLoad barrier on the SPARC. Iirc, it even requires an explicit
>>>> membar on the x86. MFENCE, or XCHG which has the lock prefix
>>>> automatically asserted. Humm... There is a way to get around that
>>>> bastard #StoreLoad membar... It uses an async sync setup. The funny
>>>> thing is that Windows has a API that can be used to actually implement
>>>> it! Try to think of a so called, remote memory barrier, in a sense:
>>>>
>>>> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers
>>>>
>>>> There is a way to use this to get an async mutex that is kind of sort of
>>>> akin to a read write mutex. Basically, the mutex is broken down into two
>>>> parts. One that represents accesses that _very_ frequently called upon.
>>>> The other one is used rather rarely. This is the async nature that can
>>>> be exploited in rather interesting ways. I implemented some in the past
>>>> with Dmitry Vyukov. Also, this FlushProcessWriteBuffers API can be used
>>>> to implement other rather exotic sync schemes. They have very excellent
>>>> performance for certain workloads. Actually, there is a way to use it to
>>>> get a RCU in userspace and/or hazard pointers without any explicit
>>>> #StoreLoad membars.
>>>>
>>>>
>>>
>>> I would expect FlushProcessWriteBuffers() to be 2 orders of magnitude
>>> slower than #StoreLoad membar. I could be wrong, of course, the function
>>> is close to undocumented.
>> FlushProcessWriteBuffers() can be used to gain a quiescent state wrt
>> memory visibility for some exotic async algorithms, it is called in
>> certain places and is RARE. However, on the other hand, having to use a
>> #StoreLoad membar on the fast path is not good. Keep in mind that this
>> is meant to handle a store followed by a load to another location
>> scenario. We need to honor the #StoreLoad relationship for this type of
>> setup for these types of algorithms. For instance, hazard pointers
>> require a #StoreLoad, however there is a way to eliminate them using
>> some special magic wrt RCU...
>>
>> My friend Joe Seigh created SMR+RCU to gain this. SMR is hazard
>> pointers. Now, keep in mind that these are very "specialized" algorithms
>> that try to make certain workloads MUCH faster and way more efficient.
>> They work for that.
>>
>> Also, keep in mind that a normal mutex does not require #StoreLoad. Only
>> acquire and release:
>>
>> acquire = #LoadStore | #LoadLoad
>> release = #LoadStore | #StoreStore
>>
>> In SPARC parlance. For instance, an atomic store on x86 automatically
>> implies release. Btw, have you ever worked with SPARC in RMO mode? Its
>> fun because its so weak.
>>
>
> We discussed it already. I don't think that SPARCv9 RMO hardware
> ever existed and you failed to convince me otherwise.

Iirc, SPARC64 V9 can put into RMO mode.

>
> As to weakness, I don't think that by specification it is weaker than IPF,
> may be not even weaker than POWER. Certainly stronger than Alpha.
> But it does not matter since it does not exist.
>
>> I still need to find that old paper called QPI, if I remember correctly.
>> It should still be out there. I will try to find it sometime today.
>>
>> It think is was from Dice wrt a Java VM. David Dice? Damn I cannot
>> remember it right now. Sorry. ;^o
>>
>>
>> [...]

On 9/26/2023 1:58 PM, Michael S wrote:
> On Tuesday, September 26, 2023 at 10:59:06 PM UTC+3, Chris M. Thomasson wrote:
>> On 9/26/2023 9:05 AM, Michael S wrote:
>>> On Tuesday, September 26, 2023 at 8:53:13 AM UTC+3, Chris M. Thomasson wrote:
>>>> On 9/24/2023 10:04 AM, Kaz Kylheku wrote:
>>>>> On 2023-09-24, Bonita Montero <Bonita....@gmail.com> wrote:
>>>>>> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku:
>>>>>>
>>>>>>> A possible design is that each *thread* has a wait semaphore.
>>>>>>
>>>>>> You'd have to register the binary semaphore and register as a waiter in
>>>>>> one atomic step. You could do that with a DCAS'd ring, but you coudn't
>>>>>> atomically update the link pointers of the other nodes at the same
>>>>>> time you update the roots link pointers. And you would have the deallo-
>>>>>> cation poblem, i.e. the memory of your object may never be deallocated.
>>>>>
>>>>> Now you're just throwing together words you don't understand.
>>>>>
>>>>>> Show me your implementation !
>>>>>
>>>>> E.g. old LinuxThreads in glibc, circa 2000:
>>>>>
>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe
>>>>>
>>>>> The low level __pthread_lock and __pthread_unlock functions maintain a
>>>>> queue, using a single-word atomic CAS.
>>>>>
>>>>> There are suspend() and resume() functions for the waiting;
>>>>> they are elsewhere.
>>>>>
>>>>> If you look in restart.h you can see that those operations are defined
>>>>> in two different ways, both of which use signals (not a semaphore per
>>>>> thread). A suspending thread waits for the arrival of a signal,
>>>>> resume is done by sending a signal. That's kind of semaphore-like;
>>>>> and POSIX real-time signals can even queue up, like a counting sem.
>>>>>
>>>>>> It's ridiculous because mutex are a cheap resource. And if such imple-
>>>>>> mentation would be possible the standard shouldn't mandate it since
>>>>>> not every platform has a DCAS.
>>>>>
>>>>> Things can be done in ways you havn't thought about.
>>>>>
>>>>> Atomic operations aren't required to achieve mutual exclusion among
>>>>> processors that share memory.
>>>>>
>>>>> As someone continually insisting on having expertise in concurrency,
>>>>> you must be familiar with the research work of Leslie Lamport?
>>>>
>>>> Iirc, that uses atomic loads, stores and membars. Iirc, it requires a
>>>> #StoreLoad barrier on the SPARC. Iirc, it even requires an explicit
>>>> membar on the x86. MFENCE, or XCHG which has the lock prefix
>>>> automatically asserted. Humm... There is a way to get around that
>>>> bastard #StoreLoad membar... It uses an async sync setup. The funny
>>>> thing is that Windows has a API that can be used to actually implement
>>>> it! Try to think of a so called, remote memory barrier, in a sense:
>>>>
>>>> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers
>>>>
>>>> There is a way to use this to get an async mutex that is kind of sort of
>>>> akin to a read write mutex. Basically, the mutex is broken down into two
>>>> parts. One that represents accesses that _very_ frequently called upon.
>>>> The other one is used rather rarely. This is the async nature that can
>>>> be exploited in rather interesting ways. I implemented some in the past
>>>> with Dmitry Vyukov. Also, this FlushProcessWriteBuffers API can be used
>>>> to implement other rather exotic sync schemes. They have very excellent
>>>> performance for certain workloads. Actually, there is a way to use it to
>>>> get a RCU in userspace and/or hazard pointers without any explicit
>>>> #StoreLoad membars.
>>>>
>>>>
>>>
>>> I would expect FlushProcessWriteBuffers() to be 2 orders of magnitude
>>> slower than #StoreLoad membar. I could be wrong, of course, the function
>>> is close to undocumented.
>> FlushProcessWriteBuffers() can be used to gain a quiescent state wrt
>> memory visibility for some exotic async algorithms, it is called in
>> certain places and is RARE. However, on the other hand, having to use a
>> #StoreLoad membar on the fast path is not good. Keep in mind that this
>> is meant to handle a store followed by a load to another location
>> scenario. We need to honor the #StoreLoad relationship for this type of
>> setup for these types of algorithms. For instance, hazard pointers
>> require a #StoreLoad, however there is a way to eliminate them using
>> some special magic wrt RCU...
>>
>> My friend Joe Seigh created SMR+RCU to gain this. SMR is hazard
>> pointers. Now, keep in mind that these are very "specialized" algorithms
>> that try to make certain workloads MUCH faster and way more efficient.
>> They work for that.
>>
>> Also, keep in mind that a normal mutex does not require #StoreLoad. Only
>> acquire and release:
>>
>> acquire = #LoadStore | #LoadLoad
>> release = #LoadStore | #StoreStore
>>
>> In SPARC parlance. For instance, an atomic store on x86 automatically
>> implies release. Btw, have you ever worked with SPARC in RMO mode? Its
>> fun because its so weak.
>>
>
> We discussed it already. I don't think that SPARCv9 RMO hardware
> ever existed and you failed to convince me otherwise.

Have you ever used SPARC before? Solaris?

>
> As to weakness, I don't think that by specification it is weaker than IPF,
> may be not even weaker than POWER. Certainly stronger than Alpha.
> But it does not matter since it does not exist.
>
>> I still need to find that old paper called QPI, if I remember correctly.
>> It should still be out there. I will try to find it sometime today.
>>
>> It think is was from Dice wrt a Java VM. David Dice? Damn I cannot
>> remember it right now. Sorry. ;^o
>>
>>
>> [...]

On 9/26/2023 1:58 PM, Michael S wrote:
> On Tuesday, September 26, 2023 at 10:59:06 PM UTC+3, Chris M. Thomasson wrote:
>> On 9/26/2023 9:05 AM, Michael S wrote:
>>> On Tuesday, September 26, 2023 at 8:53:13 AM UTC+3, Chris M. Thomasson wrote:
>>>> On 9/24/2023 10:04 AM, Kaz Kylheku wrote:
>>>>> On 2023-09-24, Bonita Montero <Bonita....@gmail.com> wrote:
>>>>>> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku:
>>>>>>
>>>>>>> A possible design is that each *thread* has a wait semaphore.
>>>>>>
>>>>>> You'd have to register the binary semaphore and register as a waiter in
>>>>>> one atomic step. You could do that with a DCAS'd ring, but you coudn't
>>>>>> atomically update the link pointers of the other nodes at the same
>>>>>> time you update the roots link pointers. And you would have the deallo-
>>>>>> cation poblem, i.e. the memory of your object may never be deallocated.
>>>>>
>>>>> Now you're just throwing together words you don't understand.
>>>>>
>>>>>> Show me your implementation !
>>>>>
>>>>> E.g. old LinuxThreads in glibc, circa 2000:
>>>>>
>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe
>>>>>
>>>>> The low level __pthread_lock and __pthread_unlock functions maintain a
>>>>> queue, using a single-word atomic CAS.
>>>>>
>>>>> There are suspend() and resume() functions for the waiting;
>>>>> they are elsewhere.
>>>>>
>>>>> If you look in restart.h you can see that those operations are defined
>>>>> in two different ways, both of which use signals (not a semaphore per
>>>>> thread). A suspending thread waits for the arrival of a signal,
>>>>> resume is done by sending a signal. That's kind of semaphore-like;
>>>>> and POSIX real-time signals can even queue up, like a counting sem.
>>>>>
>>>>>> It's ridiculous because mutex are a cheap resource. And if such imple-
>>>>>> mentation would be possible the standard shouldn't mandate it since
>>>>>> not every platform has a DCAS.
>>>>>
>>>>> Things can be done in ways you havn't thought about.
>>>>>
>>>>> Atomic operations aren't required to achieve mutual exclusion among
>>>>> processors that share memory.
>>>>>
>>>>> As someone continually insisting on having expertise in concurrency,
>>>>> you must be familiar with the research work of Leslie Lamport?
>>>>
>>>> Iirc, that uses atomic loads, stores and membars. Iirc, it requires a
>>>> #StoreLoad barrier on the SPARC. Iirc, it even requires an explicit
>>>> membar on the x86. MFENCE, or XCHG which has the lock prefix
>>>> automatically asserted. Humm... There is a way to get around that
>>>> bastard #StoreLoad membar... It uses an async sync setup. The funny
>>>> thing is that Windows has a API that can be used to actually implement
>>>> it! Try to think of a so called, remote memory barrier, in a sense:
>>>>
>>>> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers
>>>>
>>>> There is a way to use this to get an async mutex that is kind of sort of
>>>> akin to a read write mutex. Basically, the mutex is broken down into two
>>>> parts. One that represents accesses that _very_ frequently called upon.
>>>> The other one is used rather rarely. This is the async nature that can
>>>> be exploited in rather interesting ways. I implemented some in the past
>>>> with Dmitry Vyukov. Also, this FlushProcessWriteBuffers API can be used
>>>> to implement other rather exotic sync schemes. They have very excellent
>>>> performance for certain workloads. Actually, there is a way to use it to
>>>> get a RCU in userspace and/or hazard pointers without any explicit
>>>> #StoreLoad membars.
>>>>
>>>>
>>>
>>> I would expect FlushProcessWriteBuffers() to be 2 orders of magnitude
>>> slower than #StoreLoad membar. I could be wrong, of course, the function
>>> is close to undocumented.
>> FlushProcessWriteBuffers() can be used to gain a quiescent state wrt
>> memory visibility for some exotic async algorithms, it is called in
>> certain places and is RARE. However, on the other hand, having to use a
>> #StoreLoad membar on the fast path is not good. Keep in mind that this
>> is meant to handle a store followed by a load to another location
>> scenario. We need to honor the #StoreLoad relationship for this type of
>> setup for these types of algorithms. For instance, hazard pointers
>> require a #StoreLoad, however there is a way to eliminate them using
>> some special magic wrt RCU...
>>
>> My friend Joe Seigh created SMR+RCU to gain this. SMR is hazard
>> pointers. Now, keep in mind that these are very "specialized" algorithms
>> that try to make certain workloads MUCH faster and way more efficient.
>> They work for that.
>>
>> Also, keep in mind that a normal mutex does not require #StoreLoad. Only
>> acquire and release:
>>
>> acquire = #LoadStore | #LoadLoad
>> release = #LoadStore | #StoreStore
>>
>> In SPARC parlance. For instance, an atomic store on x86 automatically
>> implies release. Btw, have you ever worked with SPARC in RMO mode? Its
>> fun because its so weak.
>>
>
> We discussed it already. I don't think that SPARCv9 RMO hardware
> ever existed and you failed to convince me otherwise.

[...]

heck, have you ever had to use a DEC Alpha that was so weak it did not
even honor data dependent loads? This is interesting wrt RCU... ;^)

On 9/26/2023 1:58 PM, Michael S wrote:
> On Tuesday, September 26, 2023 at 10:59:06 PM UTC+3, Chris M. Thomasson wrote:
>> On 9/26/2023 9:05 AM, Michael S wrote:
>>> On Tuesday, September 26, 2023 at 8:53:13 AM UTC+3, Chris M. Thomasson wrote:
>>>> On 9/24/2023 10:04 AM, Kaz Kylheku wrote:
>>>>> On 2023-09-24, Bonita Montero <Bonita....@gmail.com> wrote:
>>>>>> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku:
>>>>>>
>>>>>>> A possible design is that each *thread* has a wait semaphore.
>>>>>>
>>>>>> You'd have to register the binary semaphore and register as a waiter in
>>>>>> one atomic step. You could do that with a DCAS'd ring, but you coudn't
>>>>>> atomically update the link pointers of the other nodes at the same
>>>>>> time you update the roots link pointers. And you would have the deallo-
>>>>>> cation poblem, i.e. the memory of your object may never be deallocated.
>>>>>
>>>>> Now you're just throwing together words you don't understand.
>>>>>
>>>>>> Show me your implementation !
>>>>>
>>>>> E.g. old LinuxThreads in glibc, circa 2000:
>>>>>
>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe
>>>>>
>>>>> The low level __pthread_lock and __pthread_unlock functions maintain a
>>>>> queue, using a single-word atomic CAS.
>>>>>
>>>>> There are suspend() and resume() functions for the waiting;
>>>>> they are elsewhere.
>>>>>
>>>>> If you look in restart.h you can see that those operations are defined
>>>>> in two different ways, both of which use signals (not a semaphore per
>>>>> thread). A suspending thread waits for the arrival of a signal,
>>>>> resume is done by sending a signal. That's kind of semaphore-like;
>>>>> and POSIX real-time signals can even queue up, like a counting sem.
>>>>>
>>>>>> It's ridiculous because mutex are a cheap resource. And if such imple-
>>>>>> mentation would be possible the standard shouldn't mandate it since
>>>>>> not every platform has a DCAS.
>>>>>
>>>>> Things can be done in ways you havn't thought about.
>>>>>
>>>>> Atomic operations aren't required to achieve mutual exclusion among
>>>>> processors that share memory.
>>>>>
>>>>> As someone continually insisting on having expertise in concurrency,
>>>>> you must be familiar with the research work of Leslie Lamport?
>>>>
>>>> Iirc, that uses atomic loads, stores and membars. Iirc, it requires a
>>>> #StoreLoad barrier on the SPARC. Iirc, it even requires an explicit
>>>> membar on the x86. MFENCE, or XCHG which has the lock prefix
>>>> automatically asserted. Humm... There is a way to get around that
>>>> bastard #StoreLoad membar... It uses an async sync setup. The funny
>>>> thing is that Windows has a API that can be used to actually implement
>>>> it! Try to think of a so called, remote memory barrier, in a sense:
>>>>
>>>> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers
>>>>
>>>> There is a way to use this to get an async mutex that is kind of sort of
>>>> akin to a read write mutex. Basically, the mutex is broken down into two
>>>> parts. One that represents accesses that _very_ frequently called upon.
>>>> The other one is used rather rarely. This is the async nature that can
>>>> be exploited in rather interesting ways. I implemented some in the past
>>>> with Dmitry Vyukov. Also, this FlushProcessWriteBuffers API can be used
>>>> to implement other rather exotic sync schemes. They have very excellent
>>>> performance for certain workloads. Actually, there is a way to use it to
>>>> get a RCU in userspace and/or hazard pointers without any explicit
>>>> #StoreLoad membars.
>>>>
>>>>
>>>
>>> I would expect FlushProcessWriteBuffers() to be 2 orders of magnitude
>>> slower than #StoreLoad membar. I could be wrong, of course, the function
>>> is close to undocumented.
>> FlushProcessWriteBuffers() can be used to gain a quiescent state wrt
>> memory visibility for some exotic async algorithms, it is called in
>> certain places and is RARE. However, on the other hand, having to use a
>> #StoreLoad membar on the fast path is not good. Keep in mind that this
>> is meant to handle a store followed by a load to another location
>> scenario. We need to honor the #StoreLoad relationship for this type of
>> setup for these types of algorithms. For instance, hazard pointers
>> require a #StoreLoad, however there is a way to eliminate them using
>> some special magic wrt RCU...
>>
>> My friend Joe Seigh created SMR+RCU to gain this. SMR is hazard
>> pointers. Now, keep in mind that these are very "specialized" algorithms
>> that try to make certain workloads MUCH faster and way more efficient.
>> They work for that.
>>
>> Also, keep in mind that a normal mutex does not require #StoreLoad. Only
>> acquire and release:
>>
>> acquire = #LoadStore | #LoadLoad
>> release = #LoadStore | #StoreStore
>>
>> In SPARC parlance. For instance, an atomic store on x86 automatically
>> implies release. Btw, have you ever worked with SPARC in RMO mode? Its
>> fun because its so weak.
>>
>
> We discussed it already. I don't think that SPARCv9 RMO hardware
> ever existed and you failed to convince me otherwise.
>
> As to weakness, I don't think that by specification it is weaker than IPF,
> may be not even weaker than POWER. Certainly stronger than Alpha.

The damn DEC Alpha did not even honor data-dependent loads, that is very
weak. It's so weak it has to use membars to implement RCU.

Sparc in RMO mode requires explicit MEMBAR for acquire and release. IN
TSO mode it had implicit acquire and release wrt loads and stores much
like x86.

On 9/25/2023 11:08 AM, Kaz Kylheku wrote:
> On 2023-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 25.09.2023 um 13:15 schrieb Richard Damon:
>>
>>> You argument is basically, the Standard needs to allow for BAD
>>> implementation to exist.
>>
>> And implementation that throws in this situation isn't bad for me.
>
> An implementation that throws in mutex locks that aren't process-shared
> robust mutexes or anything of that sort is a ... sick joke.
>

Big time.

On 9/21/2023 11:42 AM, Kaz Kylheku wrote:
> On 2023-09-21, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 9/21/2023 5:40 AM, Bonita Montero wrote:
>>> Am 21.09.2023 um 13:36 schrieb Richard Damon:
>>>
>>>> Why?
>>>
>>> Because the initialization might only take a microsecond or less
>>> and a yield is a full timeslice, on Linux and Windows usually one
>>> millisecond.
>>
>> An adaptive backoff can be a mixture of the PAUSE instruction aka x86,
>> and yield wrt the OS.
>
> Ideally there shouldn't be a difference? In user mode execution, PAUSE
> should be a privileged instruction. User space must not pause the
> machine until an interrupt occurs. The privileged instruction will trap
> to the kernel, where it becomes equivalent to a yield().
>
> In the kernel, the lowest-priority idle task might execute that
> instruction in a loop: the real one, not the trap.
>
> When the scheduler determines there is truly nothing to do then it is
> legitimate to dispatch an idle task which suspends the processor until
> an external event.
>

Wrt adaptive backoff, did you ever read the following paper?

https://dl.acm.org/doi/10.1145/2686884

Iirc, David was an author on the paper I am having trouble finding wrt QPI.

On 9/21/2023 11:42 AM, Kaz Kylheku wrote:
> On 2023-09-21, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 9/21/2023 5:40 AM, Bonita Montero wrote:
>>> Am 21.09.2023 um 13:36 schrieb Richard Damon:
>>>
>>>> Why?
>>>
>>> Because the initialization might only take a microsecond or less
>>> and a yield is a full timeslice, on Linux and Windows usually one
>>> millisecond.
>>
>> An adaptive backoff can be a mixture of the PAUSE instruction aka x86,
>> and yield wrt the OS.
>
> Ideally there shouldn't be a difference? In user mode execution, PAUSE
> should be a privileged instruction. User space must not pause the
> machine until an interrupt occurs. The privileged instruction will trap
> to the kernel, where it becomes equivalent to a yield().
>
> In the kernel, the lowest-priority idle task might execute that
> instruction in a loop: the real one, not the trap.
>
> When the scheduler determines there is truly nothing to do then it is
> legitimate to dispatch an idle task which suspends the processor until
> an external event.
>

Damn it! I cannot find that paper wrt QPI or the quick path interconnect
wrt Intel, and how to abuse it for even a userspace RCU.

On 9/26/23 8:36 AM, Bonita Montero wrote:
> Am 26.09.2023 um 13:23 schrieb Richard Damon:
>
>> Nope, if you do it right, a suitable synchronization object can be
>> created without possibility of error.
>
> The kernel part for the slow path is a binary semaphore. You can't
> create an aribtrary number of that on any operating system. Yieling
> is inefficient and I also mentioned why spin-locking is totally
> inacceptable.
>

Only if you do it wrong, like you are doing.

You THINK yielding is inefficient, but it really isn't.

IT only gives time to other threads that actually need it, so the
processor is kept doing useful work.

You also don't seem to understand how Schedulers ACTUALLY WORK.

Just shows your ignorance.

On 9/26/23 11:33 AM, Bonita Montero wrote:
> Am 26.09.2023 um 17:24 schrieb Scott Lurndal:
>
>> No, it is not.   The kernel simply moves the waiter thread to
>> a non-runnable queue in the dispatcher until a call to 'unlock'
>> determines that there is a waiter and tells the kernel to
>> awaken it.
>
> The userspace code must tell the kernel what it its waiting for.
> Mutexes are always a combination of an atomic for the fast path
> and a binary semapohre for the slow path.
>

Sorry to tell you that you are just wrong.

Please point to the code in the kernal that actually does this.

If you can't, your just admitting that you have been lying about knowing
how it works.

On 2023-09-26, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 26.09.2023 um 19:09 schrieb Kaz Kylheku:
>
>> In Linux, the original threads implementation in Glibc, based on
>> Xavier Leroy's LinuxThreads didn't use one semaphore per mutex.
>> It used POSIX signals to implement internal functions suspend()
>> and resume(). There was no kernel object to allocate.
>
> Maybe, but the C++ standard shoudn't mandate that. If you implement
> a mutex yourself under Windows you'd need a kernel event or semaphore.

Only if you had no imagination, research abilility, or skills for
porting ideas from elsewhere to Windows.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 9/26/23 8:33 AM, Bonita Montero wrote:
> Am 26.09.2023 um 13:42 schrieb Richard Damon:
>
>> Again, your argument boils down to: Even though there is a way to do
>> it  without failure, the fact that another, "defective" way exists
>> that might generate an error, the Standard should be modified so that
>> "defective" method can be used.
>
> Pthread mutexes can be initialized statically, but then you have the
> same kind of delayed inititialization - which may fail. Or if you
> create the kernel part along with the initialization dynamically;
> then it doesn't fit with std::mutex' constructor which is noexcept.
> So in either way this operation may fail.
> I don't know what's the problem for further discussions that ::lock()
> simply may fail at least because of delayed initialization, on some
> operating systems also because of synchronization.
> And the standard can't assume a certain operation but in my opinion
> even has to assume that there are platforms that even may fail on
> synchronization, maybe because the kernel queue entries are allocated
> dynamically or whatevery.
> And it's the same for static local initialization, no matter if this
> initialization actually uses a std::mutex or whatever - because in
> any case there's a mutex behind to make contending threads sleeping
> as documented by the stdandardd. I also mentioned many times why
> yieling is inefficient and unprofessional here.
>

Please point to the error that a properly created and used pthread_mutex
can give on a lock that represents a mutex creation error.

Remember, we are talking about in INTRA-process mutex, not an
INTER-process mutex.

Yes, C++ allows lock to fails if the OS gives an error, but in POSIX
there is no error possible for this type of mutex when used correctly.

You keep on thinking that something can fail, and yes, it can if you do
things wrong, but not if you do things right.

All you are arguing is that the Standard should allow BUGGY
implementations to still be correct.

I guess this just shows the quality of your own code, that you need
people to accept your buggy code as correct.

Those of us who have to write code that actually works correctly, will
disagree with you, and we will be correct, and you wrong.

You have really effectively admitted you are lying because you have made
claims that have been shown to be totally incorrect.

On 9/26/23 1:33 PM, Bonita Montero wrote:
> Am 26.09.2023 um 19:09 schrieb Kaz Kylheku:
>
>> In Linux, the original threads implementation in Glibc, based on
>> Xavier Leroy's LinuxThreads didn't use one semaphore per mutex.
>> It used POSIX signals to implement internal functions suspend()
>> and resume().  There was no kernel object to allocate.
>
> Maybe, but the C++ standard shoudn't mandate that. If you implement
> a mutex yourself under Windows you'd need a kernel event or semaphore.
>
>

Right, but if your mutexs can fail, you can't use them for static
initialization that can't fail.

All you keep on doing is insisting that the Standard needs to allow for
buggy implementations. It doesn't.

The Standard gives allowance at times for hardware platforms with
certain limitations, but tends not to give allowance for the implementer
just being lazy.

It may allow an implementation to minimize the work it needs to do to
have a (barely) compliant implementation, but does require the
implementer to put in the work (and have the knowledge) to actually
implement things correctly.

On 9/26/23 1:30 PM, Bonita Montero wrote:
> Am 26.09.2023 um 19:00 schrieb Michael S:
>
>> If you were reading my post up to the end you were understanding that
>> such possibility is extremely low.
>
> I think that's a common optimization since in many cases mutexes aren't
> contended at all, thereby not needing any semaphore, or contended very
> late.
>

This just shows your whole problem. You "Think" something is a given
way, but you don't actually KNOW any of the stuff you claim (you can't,
since so much is false).

Your instance that it must be "your way" is just proving your ignorance.

When asked for proof, you just waffle, which just proves your ignorance
of the topic, and that your claims are without merit.

On 9/26/2023 6:32 PM, Richard Damon wrote:
> On 9/26/23 1:30 PM, Bonita Montero wrote:
>> Am 26.09.2023 um 19:00 schrieb Michael S:
>>
>>> If you were reading my post up to the end you were understanding that
>>> such possibility is extremely low.
>>
>> I think that's a common optimization since in many cases mutexes aren't
>> contended at all, thereby not needing any semaphore, or contended very
>> late.
>>
>
> This just shows your whole problem. You "Think" something is a given
> way, but you don't actually KNOW any of the stuff you claim (you can't,
> since so much is false).
>
> Your instance that it must be "your way" is just proving your ignorance.
>
> When asked for proof, you just waffle, which just proves your ignorance
> of the topic, and that your claims are without merit.

I think that about sums it up, in a sense?

On 9/26/2023 6:10 PM, Richard Damon wrote:
> On 9/26/23 1:33 PM, Bonita Montero wrote:
>> Am 26.09.2023 um 19:09 schrieb Kaz Kylheku:
>>
>>> In Linux, the original threads implementation in Glibc, based on
>>> Xavier Leroy's LinuxThreads didn't use one semaphore per mutex.
>>> It used POSIX signals to implement internal functions suspend()
>>> and resume().  There was no kernel object to allocate.
>>
>> Maybe, but the C++ standard shoudn't mandate that. If you implement
>> a mutex yourself under Windows you'd need a kernel event or semaphore.
>>
>>
>
> Right, but if your mutexs can fail, you can't use them for static
> initialization that can't fail.

Excellent point! :^)

>
> All you keep on doing is insisting that the Standard needs to allow for
> buggy implementations. It doesn't.
>
> The Standard gives allowance at times for hardware platforms with
> certain limitations, but tends not to give allowance for the implementer
> just being lazy.
>
> It may allow an implementation to minimize the work it needs to do to
> have a (barely) compliant implementation, but does require the
> implementer to put in the work (and have the knowledge) to actually
> implement things correctly.

On 9/25/2023 10:20 AM, Michael S wrote:
> On Sunday, September 24, 2023 at 9:49:44 PM UTC+3, Chris M. Thomasson wrote:
>> On 9/24/2023 11:41 AM, Chris M. Thomasson wrote:
>>> On 9/24/2023 2:50 AM, Michael S wrote:
>>>> On Sunday, September 24, 2023 at 11:09:31 AM UTC+3, Bonita Montero wrote:
>>>>> Am 24.09.2023 um 05:05 schrieb Chris M. Thomasson:
>>>>>
>>>>>> Why do you think that static initialization must use a std::mutex
>>>>>> anyway? ...
>>>>>
>>>>> Call it std::mutex or whatever. It is mandated that contenders
>>>>> are sleeping - that's not possible without sth. else than a mutex.
>>>>
>>>> Few dozens posts above I demonstrated an implementation
>>>> for pre-Vista Windows where contenders are sleeping just fine and
>>>> waking just fine and initialization of different objects proceeds
>>>> simultaneously just fine. And it does not use mutex for that.
>>>> It uses SleepEx() for wait and QueueUserApc() for wakeup.
>>>
>>> Why? APC's open up a big can of worms.
>> Oh shit. I am starting to remember some nightmare code I had to debug
>> many moon ago that used async cancellation in POSIX threads.
>>>
>>>
>
> But Windows User APC, at least pre Win11, is async only on issue
> side. On reception side it is fully synchronous and easy to reason about.

You just need to be in an alterable wait and be ready to handle it.
Okay. However, fwiw, check out how this following library handles async
pthread cancellation. Iirc, they used the kernel.

https://sourceware.org/pthreads-win32/

Btw, this lib has been around for a while.

> At least it is easy as long as you don't try to enter alertable wait
> within APC routine, which I don't do. In fact, my APC routine is Nop.
>
>>>> It uses one global mutex (in form of critical section) for a short
>>>> while for metadata updates, but that's done for simplicity and
>>>> practicality rather than out of necessity. I am pretty sure that
>>>> with enough effort I can device a variant that achieves the same
>>>> with CaS.
>>>
>>>

On Wednesday, September 27, 2023 at 5:27:52 AM UTC+3, Chris M. Thomasson wrote:
> On 9/25/2023 10:20 AM, Michael S wrote:
> > On Sunday, September 24, 2023 at 9:49:44 PM UTC+3, Chris M. Thomasson wrote:
> >> On 9/24/2023 11:41 AM, Chris M. Thomasson wrote:
> >>> On 9/24/2023 2:50 AM, Michael S wrote:
> >>>> On Sunday, September 24, 2023 at 11:09:31 AM UTC+3, Bonita Montero wrote:
> >>>>> Am 24.09.2023 um 05:05 schrieb Chris M. Thomasson:
> >>>>>
> >>>>>> Why do you think that static initialization must use a std::mutex
> >>>>>> anyway? ...
> >>>>>
> >>>>> Call it std::mutex or whatever. It is mandated that contenders
> >>>>> are sleeping - that's not possible without sth. else than a mutex.
> >>>>
> >>>> Few dozens posts above I demonstrated an implementation
> >>>> for pre-Vista Windows where contenders are sleeping just fine and
> >>>> waking just fine and initialization of different objects proceeds
> >>>> simultaneously just fine. And it does not use mutex for that.
> >>>> It uses SleepEx() for wait and QueueUserApc() for wakeup.
> >>>
> >>> Why? APC's open up a big can of worms.
> >> Oh shit. I am starting to remember some nightmare code I had to debug
> >> many moon ago that used async cancellation in POSIX threads.
> >>>
> >>>
> >
> > But Windows User APC, at least pre Win11, is async only on issue
> > side. On reception side it is fully synchronous and easy to reason about.
>
> You just need to be in an alterable wait and be ready to handle it.
> Okay. However, fwiw, check out how this following library handles async
> pthread cancellation. Iirc, they used the kernel.
>
> https://sourceware.org/pthreads-win32/
>
> Btw, this lib has been around for a while.
>

Thank you, but I am not going to look at it. Not my area of interest.

>
> > At least it is easy as long as you don't try to enter alertable wait
> > within APC routine, which I don't do. In fact, my APC routine is Nop.
> >
> >>>> It uses one global mutex (in form of critical section) for a short
> >>>> while for metadata updates, but that's done for simplicity and
> >>>> practicality rather than out of necessity. I am pretty sure that
> >>>> with enough effort I can device a variant that achieves the same
> >>>> with CaS.
> >>>
> >>>

On 9/27/2023 12:36 AM, Michael S wrote:
> On Wednesday, September 27, 2023 at 5:27:52 AM UTC+3, Chris M. Thomasson wrote:
>> On 9/25/2023 10:20 AM, Michael S wrote:
>>> On Sunday, September 24, 2023 at 9:49:44 PM UTC+3, Chris M. Thomasson wrote:
>>>> On 9/24/2023 11:41 AM, Chris M. Thomasson wrote:
>>>>> On 9/24/2023 2:50 AM, Michael S wrote:
>>>>>> On Sunday, September 24, 2023 at 11:09:31 AM UTC+3, Bonita Montero wrote:
>>>>>>> Am 24.09.2023 um 05:05 schrieb Chris M. Thomasson:
>>>>>>>
>>>>>>>> Why do you think that static initialization must use a std::mutex
>>>>>>>> anyway? ...
>>>>>>>
>>>>>>> Call it std::mutex or whatever. It is mandated that contenders
>>>>>>> are sleeping - that's not possible without sth. else than a mutex.
>>>>>>
>>>>>> Few dozens posts above I demonstrated an implementation
>>>>>> for pre-Vista Windows where contenders are sleeping just fine and
>>>>>> waking just fine and initialization of different objects proceeds
>>>>>> simultaneously just fine. And it does not use mutex for that.
>>>>>> It uses SleepEx() for wait and QueueUserApc() for wakeup.
>>>>>
>>>>> Why? APC's open up a big can of worms.
>>>> Oh shit. I am starting to remember some nightmare code I had to debug
>>>> many moon ago that used async cancellation in POSIX threads.
>>>>>
>>>>>
>>>
>>> But Windows User APC, at least pre Win11, is async only on issue
>>> side. On reception side it is fully synchronous and easy to reason about.
>>
>> You just need to be in an alterable wait and be ready to handle it.
>> Okay. However, fwiw, check out how this following library handles async
>> pthread cancellation. Iirc, they used the kernel.
>>
>> https://sourceware.org/pthreads-win32/
>>
>> Btw, this lib has been around for a while.
>>
>
> Thank you, but I am not going to look at it. Not my area of interest.

No problem. Just remember. When you are _really_ bored with nothing to
do at all... Well, its there. ;^)

>
>>
>>> At least it is easy as long as you don't try to enter alertable wait
>>> within APC routine, which I don't do. In fact, my APC routine is Nop.
>>>
>>>>>> It uses one global mutex (in form of critical section) for a short
>>>>>> while for metadata updates, but that's done for simplicity and
>>>>>> practicality rather than out of necessity. I am pretty sure that
>>>>>> with enough effort I can device a variant that achieves the same
>>>>>> with CaS.
>>>>>
>>>>>

On Tuesday, September 26, 2023 at 3:37:35 PM UTC+3, Bonita Montero wrote:
> Am 26.09.2023 um 13:23 schrieb Richard Damon:
> > But it doesn't NEED to be expected, and doing it in a way that allows
> > for failure when you can do it in a way that can't fail is just being
> > a bad implementation.
> The slow path always is backed by a binary semaphore of the kernel.
> You can't create an arbitrary number of that.

Today I tested how Critical Sections and Exclusive SRW locks are implemented
on various versions Windows (x86-64).

Critical sections on Win7/Ws2008 implemented as you guessed it - initialization
does not create kernel objects. Kernel object is created on first wait, if there were
waits. And indeed there is 1 kernel object per critical section that waited until once
and was not explicitly deleted after that.

Critical sections on Ws2016 never create kernel objects. It does not matter if they
were ever waited on or not.
I didn't test on win10, but its essentially the same kernel as
Ws2016, so I expect the same behavior with very high certainty.

Exclusive SRW locks never create kernel objects as well, on any variant of
Windows OS, but that was already obvious from the absence of destruction
method in the API.

On 9/27/2023 2:48 PM, Michael S wrote:
> On Tuesday, September 26, 2023 at 3:37:35 PM UTC+3, Bonita Montero wrote:
>> Am 26.09.2023 um 13:23 schrieb Richard Damon:
>>> But it doesn't NEED to be expected, and doing it in a way that allows
>>> for failure when you can do it in a way that can't fail is just being
>>> a bad implementation.
>> The slow path always is backed by a binary semaphore of the kernel.
>> You can't create an arbitrary number of that.
>
> Today I tested how Critical Sections and Exclusive SRW locks are implemented
> on various versions Windows (x86-64).
>
> Critical sections on Win7/Ws2008 implemented as you guessed it - initialization
> does not create kernel objects. Kernel object is created on first wait, if there were
> waits. And indeed there is 1 kernel object per critical section that waited until once
> and was not explicitly deleted after that.

Well, shit happens. Yuck.

>
> Critical sections on Ws2016 never create kernel objects. It does not matter if they
> were ever waited on or not.
> I didn't test on win10, but its essentially the same kernel as
> Ws2016, so I expect the same behavior with very high certainty.
>
> Exclusive SRW locks never create kernel objects as well, on any variant of
> Windows OS, but that was already obvious from the absence of destruction
> method in the API.
>
>
>
>

On 9/27/2023 2:48 PM, Michael S wrote:
> On Tuesday, September 26, 2023 at 3:37:35 PM UTC+3, Bonita Montero wrote:
>> Am 26.09.2023 um 13:23 schrieb Richard Damon:
>>> But it doesn't NEED to be expected, and doing it in a way that allows
>>> for failure when you can do it in a way that can't fail is just being
>>> a bad implementation.
>> The slow path always is backed by a binary semaphore of the kernel.
>> You can't create an arbitrary number of that.
>
> Today I tested how Critical Sections and Exclusive SRW locks are implemented
> on various versions Windows (x86-64).
>
> Critical sections on Win7/Ws2008 implemented as you guessed it - initialization
> does not create kernel objects. Kernel object is created on first wait, if there were
> waits. And indeed there is 1 kernel object per critical section that waited until once
> and was not explicitly deleted after that.

I cannot remember kernel keyed events were implemented in win7, I am
pretty sure they were. Have you ever messed around with those before?

>
> Critical sections on Ws2016 never create kernel objects. It does not matter if they
> were ever waited on or not.
> I didn't test on win10, but its essentially the same kernel as
> Ws2016, so I expect the same behavior with very high certainty.
>
> Exclusive SRW locks never create kernel objects as well, on any variant of
> Windows OS, but that was already obvious from the absence of destruction
> method in the API.
>
>
>
>