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.
>
> 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.
>
>
>
>

I need to examine the kernel for nt4 again:

https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos

On Thursday, September 28, 2023 at 1:15:22 AM UTC+3, Chris M. Thomasson wrote:
> 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?

I have no idea what the phrase "kernel keyed events" means.

> >
> > 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 2023-09-27, Michael S <already5chosen@yahoo.com> wrote:
> 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.

Could this in any way be related to Microsoft evidently obtaining a patent on
futexes in 2014?

--
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.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>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.
>>
>> 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.
>>
>>
>>
>>
>
>I need to examine the kernel for nt4 again:
>
>https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos

Why? It's a quarter century old. Did it even support threads?

On 9/27/2023 3:37 PM, Scott Lurndal wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> 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.
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>
>> I need to examine the kernel for nt4 again:
>>
>> https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos
>
> Why? It's a quarter century old. Did it even support threads?
>

NT 4? Yup, it supported threads.

On 9/27/2023 3:25 PM, Michael S wrote:
> On Thursday, September 28, 2023 at 1:15:22 AM UTC+3, Chris M. Thomasson wrote:
>> 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?
>
> I have no idea what the phrase "kernel keyed events" means.

There is a sync object in windows called a keyed event, however I think
its only for the kernel. Iirc, I learned about it in a sysinternals
magazine. Forgot the issue number. It is a special type of Windows Event
object.

>
>>>
>>> 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 3:27 PM, Kaz Kylheku wrote:
> On 2023-09-27, Michael S <already5chosen@yahoo.com> wrote:
>> 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.
>
> Could this in any way be related to Microsoft evidently obtaining a patent on
> futexes in 2014?
>

NO SHIT!!! ;^o wow.!

On Thursday, September 28, 2023 at 1:37:48 AM UTC+3, Scott Lurndal wrote:
> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
> >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.
> >>
> >> 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.
> >>
> >>
> >>
> >>
> >
> >I need to examine the kernel for nt4 again:
> >
> >https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos
> Why? It's a quarter century old. Did it even support threads?

Windows Nt supports threads since its very first version, non-intuitively
named 3.1. I.e. 30 years.

On 9/27/2023 3:59 PM, Michael S wrote:
> On Thursday, September 28, 2023 at 1:37:48 AM UTC+3, Scott Lurndal wrote:
>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>> 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.
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>
>>> I need to examine the kernel for nt4 again:
>>>
>>> https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos
>> Why? It's a quarter century old. Did it even support threads?
>
> Windows Nt supports threads since its very first version,

Yup. You are correct. Windows NT 4 even had IOCP.

> non-intuitively named 3.1. I.e. 30 years.

On Thursday, September 28, 2023 at 2:06:33 AM UTC+3, Chris M. Thomasson wrote:
> On 9/27/2023 3:59 PM, Michael S wrote:
> > On Thursday, September 28, 2023 at 1:37:48 AM UTC+3, Scott Lurndal wrote:
> >> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
> >>> 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.
> >>>>
> >>>> 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.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> I need to examine the kernel for nt4 again:
> >>>
> >>> https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos
> >> Why? It's a quarter century old. Did it even support threads?
> >
> > Windows Nt supports threads since its very first version,
> Yup. You are correct. Windows NT 4 even had IOCP.

Didn't IOCP come earlier? Nt 3.5?

> > non-intuitively named 3.1. I.e. 30 years.

On 9/27/2023 4:10 PM, Michael S wrote:
> On Thursday, September 28, 2023 at 2:06:33 AM UTC+3, Chris M. Thomasson wrote:
>> On 9/27/2023 3:59 PM, Michael S wrote:
>>> On Thursday, September 28, 2023 at 1:37:48 AM UTC+3, Scott Lurndal wrote:
>>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> I need to examine the kernel for nt4 again:
>>>>>
>>>>> https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos
>>>> Why? It's a quarter century old. Did it even support threads?
>>>
>>> Windows Nt supports threads since its very first version,
>> Yup. You are correct. Windows NT 4 even had IOCP.
>
> Didn't IOCP come earlier? Nt 3.5?

Good question. I cannot remember right now! I used it a lot in NT 4.
Shit, your question kind of got me here. I cannot remember right now.
Anyway, thanks for the brain sparks, Michael!

>
>>> non-intuitively named 3.1. I.e. 30 years.

On Thursday, September 28, 2023 at 1:27:57 AM UTC+3, Kaz Kylheku wrote:
> On 2023-09-27, Michael S <already...@yahoo.com> wrote:
> > 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.
> Could this in any way be related to Microsoft evidently obtaining a patent on
> futexes in 2014?
> --

It's not all roses.
According to my preliminary measurements when the thread is blocked on
Critical Section or on Exclusive SRW lock, Ws2016 scheduler is an order of
magnitude slower than Ws2008 in granting the core to another ready thread.

At least, that's what happens when both threads are manually assigned to the
same core by SetThreadAffinityMask(). May be, in less artificial situations
it's not that bad, I didn't figure out yet how to test that.

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

On Thursday, September 28, 2023 at 12:48:42 AM UTC+3, 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.

Under further exploration it turned out somewhat less simple.
1 kernel object per critical section that ever waited is true up to slightly
less than 16M kernel objects. The number of kernel objects stops to grow after
that, but critical sections continue to work as expected and slow path does not
become observably slower. So, it seems, the infrastructure for sharing of one
kernel object per multiple Critical Section instances already exists in pre-10
Windows. But it is triggered at very different point.

However now I am certain that huge number of Critical Sections [that waited] is
supported just fine on Win7/Ws2008. I tried 200,000,000 critical sections, that's
8 GB for critical sections storage alone. It works flawlessly.

So, even on this old variant of Windows OS Bonita is wrong - lock() method of
non-shared mutex can't fail due to deficit of kernel objects.

>
> 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.

Am 28.09.2023 um 13:07 schrieb Michael S:

> Under further exploration it turned out somewhat less simple.
> 1 kernel object per critical section that ever waited is true up to slightly
> less than 16M kernel objects. The number of kernel objects stops to grow after
> that, but critical sections continue to work as expected and slow path does not
> become observably slower. ...
Show me your code.

On Thursday, September 28, 2023 at 2:25:01 PM UTC+3, Bonita Montero wrote:
> Am 28.09.2023 um 13:07 schrieb Michael S:
>
> > Under further exploration it turned out somewhat less simple.
> > 1 kernel object per critical section that ever waited is true up to slightly
> > less than 16M kernel objects. The number of kernel objects stops to grow after
> > that, but critical sections continue to work as expected and slow path does not
> > become observably slower. ...
> Show me your code.

I can, but you wouldn't understand.

Am 28.09.2023 um 13:46 schrieb Michael S:

> I can, but you wouldn't understand.

Of course I would understand that. But I'm aware of the 2 ^ 24 handle
per process limit and I'm asking myself how it would be possible to
have so much mutex-associated handles as well as at least half the
number of threads, which are associated with a handle also. I guess
you never investigated that.

On Thursday, September 28, 2023 at 3:46:43 PM UTC+3, Bonita Montero wrote:
> Am 28.09.2023 um 13:46 schrieb Michael S:
>
> > I can, but you wouldn't understand.
> Of course I would understand that. But I'm aware of the 2 ^ 24 handle
> per process limit and I'm asking myself how it would be possible to
> have so much mutex-associated handles as well as at least half the
> number of threads, which are associated with a handle also. I guess
> you never investigated that.

I'll store my code on github later today. Around 21:00 UTC.

On Thursday, September 28, 2023 at 3:46:43 PM UTC+3, Bonita Montero wrote:
> Am 28.09.2023 um 13:46 schrieb Michael S:
>
> > I can, but you wouldn't understand.
> Of course I would understand that.

https://github.com/already5chosen/others/tree/master/win_mutex_tests

> But I'm aware of the 2 ^ 24 handle
> per process limit and I'm asking myself how it would be possible to
> have so much mutex-associated handles as well as at least half the
> number of threads, which are associated with a handle also. I guess
> you never investigated that.

My tests use small # of threads (3), but can wait, sequentially, on lots
of critical sections.

Chris M. Thomasson wrote:
> 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.
2008 is before 2012; hence the requirement for infallible
synchronization for C++ static initialization did not exist back then,
at least not officially. When the new standard appeared, Microsoft
implemented better sync. primitives.

That's what I already wrote somewhere above: it's not the standard that
needs to honor platform limitations; it's the platforms that will honor
a reasonable spec of the standard (or leave unfulfilled the unreasonable
one). Obviously, infallible sync for static init is not unreasonable at all.

>
>
>>
>> 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.
>>
>>
>>
>>
>

Bonita Montero wrote:
> Am 26.09.2023 um 18:46 schrieb Kaz Kylheku:
>
>> You probably don't choose a platform where mutexes require resources
>> that are only allocated on lock contention, and which can then blow up.
>
> Contention is always possible and always expensive.
>
>> Memory overcommit is enabled on most GNU/Linux system installations.
>> This means that memory allocations can fail not when you allocate
>> the memory (e.g. mmap() returning MAP_FAILED or malloc returning null)
>> but when you try to access the memory.
>
> Memory overcommit partitially bases on swappable memory. Seamphores are
> in non-pageable memory inside the kernel. But I accept what you mean: if
> you accept that an application can suddenly terminate because of the OOM
> killer you also might accept that it would be terminated because a sin-
> gle kernel semaphore coudn't be created. That may be acceptable for most
> users but if there's an error code from the kernel this still should be
> forwarded through your runtime for those who coudln't accept that.
>
I thought you were already shown that memory allocation or commit is
not necessary for static initialization synchronization in some earlier
post by Kaz Kylheku that you apparently did not want to understand.

Maybe the below will be more clear.

You can have a static user-space word (like a futex) and a per-thread
double-linked entry with a pointer that points to that user-space word
if the thread "slow-waits" for lock on that user-space futex.

Pointers to all such links can be collected to a single hashtable (of
size of the number of threads slow-waiting for mutex) where the hash
function is computed from the address of the user-space word and the
equivalence is the equality of that address. The hash entries are only
added or removed when threads are created and destroyed.

This way, the kernel space needed for "slow-waiting" is a constant x the
number of threads; hence this space does not need to be allocated other
than when the thread is created (and NOT when a synchronization
primitive is initialized or locked).

For static C++ initialization, the user-space words are
constant-initialized static ints or whatever other integral type is used
so they all are allocated at program loading time. Hence, this cannot
fail either.

To summarize, no kernel or user-space resource need to be allocated in
for either initializing or locking the synchronization primitive (which,
for C++ static var initialization purpose, will likely not be a mutex
but call-once control entirely fit in that single user-space word; but a
mutex can also work in the same infallible way just in case you wondered).

Therefore, locking does not have to be fallible for kernel resource
allocation purpose and C++ standard is good as it is in this regard.

Chris M. Thomasson wrote:
> On 9/25/2023 6:53 PM, Pavel wrote:
>> Bonita Montero wrote:
>>> Am 25.09.2023 um 03:15 schrieb Richard Damon:
>>>
>>>> Not for pthreads, ...
>>>
>>> The standard honors plattforms where an error may arise,
>>> so it should also do that for static initialization.
>>>
>> The standard does not honor platforms, it's the C++ implementation on
>> a platform might or might not honor the standard.
>
> Ding! You got it, Pavel. :^)
>
> Let's say I have a new experimental system that I want to be able to
> work with POSIX. Therefore, I need to create all of the necessary
> machinery to make it a reality, so to speak. I even have to create a
> special C compiler for my new system to help things move along... This
> would be the work that I have to put into gaining an actual
> implementation that adheres to POSIX and C while providing all of the
> required APIs...
>
> I need to make damn sure that they all work according to POSIX. If I
> want to create a C++/C 11 impl, I can perhaps even use the POSIX port
> for it. You never know. ;^)
>
> I think this aligns okay with your main point, Pavel?
>
> :^)
Sure it does. Thanks!

On 9/28/2023 5:46 AM, Bonita Montero wrote:
> Am 28.09.2023 um 13:46 schrieb Michael S:
>
>> I can, but you wouldn't understand.
>
> Of course I would understand that. But I'm aware of the 2 ^ 24 handle
> per process limit and I'm asking myself how it would be possible to
> have so much mutex-associated handles as well as at least half the
> number of threads, which are associated with a handle also. I guess
> you never investigated that.
>

Humm, perhaps the test should contain 16^16 threads? You need to study up.

On 9/28/2023 6:20 PM, Pavel wrote:
> Bonita Montero wrote:
>> Am 26.09.2023 um 18:46 schrieb Kaz Kylheku:
>>
>>> You probably don't choose a platform where mutexes require resources
>>> that are only allocated on lock contention, and which can then blow up.
>>
>> Contention is always possible and always expensive.
>>
>>> Memory overcommit is enabled on most GNU/Linux system installations.
>>> This means that memory allocations can fail not when you allocate
>>> the memory (e.g. mmap() returning MAP_FAILED or malloc returning null)
>>> but when you try to access the memory.
>>
>> Memory overcommit partitially bases on swappable memory. Seamphores are
>> in non-pageable memory inside the kernel. But I accept what you mean: if
>> you accept that an application can suddenly terminate because of the OOM
>> killer you also might accept that it would be terminated because a sin-
>> gle kernel semaphore coudn't be created. That may be acceptable for most
>> users but if there's an error code from the kernel this still should be
>> forwarded through your runtime for those who coudln't accept that.
>>
> I thought you were already shown that memory allocation or commit  is
> not necessary for static initialization synchronization in some earlier
> post by Kaz Kylheku that you apparently did not want to understand.
>
> Maybe the below will be more clear.
>
> You can have a static user-space word (like a futex) and a per-thread
> double-linked entry with a pointer that points to that user-space word
> if the thread "slow-waits" for lock on that user-space futex.
>
> Pointers to all such links can be collected to a single hashtable (of
> size of the number of threads slow-waiting for mutex) where the hash
> function is computed from the address of the user-space word and the
> equivalence is the equality of that address. The hash entries are only
> added or removed when threads are created and destroyed.
>
> This way, the kernel space needed for "slow-waiting" is a constant x the
> number of threads; hence this space does not need to be allocated other
> than when the thread is created (and NOT when a synchronization
> primitive is initialized or locked).
>
> For static C++ initialization, the user-space words are
> constant-initialized static ints or whatever other integral type is used
> so they all are allocated at program loading time. Hence, this cannot
> fail either.
>
> To summarize, no kernel or user-space resource need to be allocated in
> for either initializing or locking the synchronization primitive (which,
> for C++ static var initialization purpose, will likely not be a mutex
> but call-once control entirely fit in that single user-space word; but a
> mutex can also work in the same infallible way just in case you wondered).
>
> Therefore, locking does not have to be fallible for kernel resource
> allocation purpose and C++ standard is good as it is in this regard.
>

I have a feeling that Bonita will not understand 99.999...% of this and
call you some sort of insulting name, or something. ;^)

Bonita Montero wrote:
> Am 26.09.2023 um 03:47 schrieb Pavel:
>
>> On *some* C++ mutex the lock() method might throw. This does not
>> matter because such C++ mutex:
>
> That's enough to expect that to be portable.
What? throwing? -- Not if those *some* C++ mutex types are not needed to
implement C++ static var initialization and non-throwing and faster type
is available.

>
>> a. does not have to be used for C++ static initialization; ...
>
> I already mentioned that myself, but if there's some other kind of
> mutex this also *may* happen on some platforms. Therefore it should
> be defined this way.
>
So far you have not pointed to such a platform that would appear or stay
current and non-supporting after C++11 spec release.

As I said before, C++ implementations on platforms should and do try to
honor reasonable standard specs, not the other way around. This way the
platform try to distinguish themselves and attract more apps and then
others have to follow. This is called "progress". Catering to
least-common-denominator never worked (but, in this particular case,
nobody even referred to a platform that can't comply so adding
fallibility to static initialization (and breaking tons of old code at
that) wouldn't even be anyhow justified).

Bonita Montero wrote:
> Am 26.09.2023 um 17:25 schrieb Scott Lurndal:
>
>> No, there is no delayed initialization with pthread mutexes.
>
> There must be since you can't create a semaphore by pure assignment.
>
See mine or earlier Kaz's explanations above for how you actually can do
it (and how, iirc, it is done on Linux).