On 9/9/2023 12:17 PM, Bonita Montero wrote:
> Am 09.09.2023 um 20:49 schrieb Chris M. Thomasson:
>
>> Huh? pthread_once totally applies here. Windows has futex like abilities.
>
> It doesn't matter what Posix or Win32 says.

Are you sure about that?

> The standard should
> honour that static initialization might fail because of creating
> a synchronization primitive or synchronizing on them. The standard
> shoudln't require that this never fails.
>

Might fail? For what reasons?

On 9/9/2023 12:17 PM, Bonita Montero wrote:
> Am 09.09.2023 um 20:49 schrieb Chris M. Thomasson:
>
>> Huh? pthread_once totally applies here. Windows has futex like abilities.
>
> It doesn't matter what Posix or Win32 says. The standard should
> honour that static initialization might fail because of creating
> a synchronization primitive or synchronizing on them. The standard
> shoudln't require that this never fails.
>

Are you talking about a user object that is statically initialized
failing, throwing an exception, calling exit, or something?

On 9/8/2023 6:45 PM, Chris M. Thomasson wrote:
> On 9/8/2023 6:22 PM, Chris M. Thomasson wrote:
>> On 9/7/2023 2:55 AM, Paavo Helde wrote:
>>> 06.09.2023 21:15 Bonita Montero kirjutas:
>>>> With C++11 static local or global data is initialized thread-safe.
>>>> This is  usually done with double checked locking (DCL). DCL needs
>>>> a flag along with the static data which shows if the data already
>>>> is initialized and a mutex which guards the initalization.
>>>> I assumed that an implementation simply would use a central mutex
>>>> for all static data objects since it includes a kernel semaphore,
>>>> which is a costly resource.
>>>> To find out if this is true I wrote the below application:
>>> [...]
>>>> SleepAtInitialize<IObj> is instantiated only once per thread with this
>>>> code. So the threads don't share a central object. If there would be
>>>> a central mutex used the above code would run for about 10s. But the
>>>> code does run about one second,
>>>
>>> There is a note in the standard: "[Note: This definition permits
>>> initialization of a sequence of ordered variables concurrently with
>>> another sequence. —end note]"
>>>
>>>   i.e. there are indivual mutexes per
>>>> each instantiation of SleepAtInitiaize<>. I.e. the creation of the
>>>> mutex is also done with the static initialization. The mutex
>>>> constructor
>>>> is noexcept, so mutexes always must be created on their first use. This
>>>> is done while the DCL-locked creation of the static object. So at last
>>>> static initialization should be declared to throw a system_errror. But
>>>> I can't find anything about that in the standard.
>>>
>>> Some debugging with VS2022 seems to indicate it is using a Windows
>>> critical section for thread-safe statics initialization.
>>> EnterCriticalSection() does not return any error code and of course
>>> does not throw any C++ exceptions either, so it is supposed to never
>>> fail.
>>
>> If it does fail, then some rather radical shit has hit the fan.
>>
>>
>>>
>>> Yes, it's true it can throw a Windows structured exception
>>> EXCEPTION_POSSIBLE_DEADLOCK (after 30 days by default). But this
>>> would be considered as a fault in the program. This is what the C++
>>> standard says about deadlocks (again a footnote):
>>>
>>> "The implementation must not introduce any deadlock around execution
>>> of the initializer. Deadlocks might still be caused by the program
>>> logic; the implementation need only avoid deadlocks due to its own
>>> synchronization operations."
>>>
>>> So I gather that in case the thread-safe static init synchronization
>>> fails, there must be a bug in the implementation. No C++ exceptions
>>> would be thrown anyway.
>>
>> Right. The implementation must get it right using fine grain locking,
>> amortized table locking, or some other means. The compiler and POSIX
>> worth together like a system. Iirc, I saw another way that was
>> lock-free, but allowed a thread to create an object, then might have
>> to delete it because it was not the first one to be installed in the
>> sense of being visible to other threads. This was decades ago, iirc it
>> used CAS. No mutex.
>
> Iirc it was something like:
>
> static foo* g_foo = nullptr;
>
> foo* l_foo = g_foo; // atomic load
>
> if (! l_foo)
> {
>   foo* t_foo = new foo;
>   foo* cmp = nullptr;
>
>   // CAS would update the comparand on failure.
>   // Take special note of that...
>
>   // mb release
>
>   if (! CAS(&g_foo, &cmp, t_foo)) // atomic rmw
>   {
>     // failed!!! well, shit happens!
>     delete t_foo;
>     t_foo = cmp;
>     // mb acquire
>   }

// God damn it! There is a bug right here.
// I forgot to set l_foo to t_foo.

SHIT!

l_foo = t_foo;

God damn it!

> }
>
> else
> {
>   // mb acquire
> }
>
> l_foo->bar();

On 9/7/2023 2:55 AM, Paavo Helde wrote:
[...]

I should create a new thread for this, but this is my corrected
pseudo-code. I forgot to set l_foo to t_foo in my previous code. So
sorry about that nonsense.

static foo* g_foo = nullptr;

foo* l_foo = g_foo; // atomic load

if (! l_foo)
{ foo* t_foo = new foo;
foo* cmp = nullptr;

// CAS would update the comparand on failure.
// Take special note of that...

// mb release

if (! CAS(&g_foo, &cmp, t_foo)) // atomic rmw
{
// failed!!! well, shit happens!
delete t_foo;
t_foo = cmp;
// mb acquire
}

// I forgot to do this in my prior pseudo code.
// ARGH!!! ;^o

l_foo = t_foo; // damn it, sorry again.
}

else
{ // mb acquire
}

l_foo->bar();

Am 09.09.2023 um 21:20 schrieb Chris M. Thomasson:

>> It doesn't matter what Posix or Win32 says.

> Are you sure about that?

The standard is operating system agnostic.

> Might fail? For what reasons?

F.e. because there's no more non-pageable memory for a semaphore.

On 9/9/2023 12:55 PM, Bonita Montero wrote:
> Am 09.09.2023 um 21:20 schrieb Chris M. Thomasson:
>
>>> It doesn't matter what Posix or Win32 says.
>
>> Are you sure about that?
>
> The standard is operating system agnostic.
>
>> Might fail? For what reasons?
>
> F.e. because there's no more non-pageable memory for a semaphore.
>

An address based hash into a table based approach works by creating
everything up front. If this fails, then the user program logic is not
even executed at all.

On 9/9/2023 12:59 PM, Chris M. Thomasson wrote:
> On 9/9/2023 12:55 PM, Bonita Montero wrote:
>> Am 09.09.2023 um 21:20 schrieb Chris M. Thomasson:
>>
>>>> It doesn't matter what Posix or Win32 says.
>>
>>> Are you sure about that?
>>
>> The standard is operating system agnostic.
>>
>>> Might fail? For what reasons?
>>
>> F.e. because there's no more non-pageable memory for a semaphore.
>>
>
> An address based hash into a table based approach works by creating
> everything up front. If this fails, then the user program logic is not
> even executed at all.

Just one way.

On 9/9/23 12:15 PM, Bonita Montero wrote:
> Am 09.09.2023 um 19:42 schrieb Pavel:
>
>> If Microsoft implemented standard wrongly, it's Microsoft's failure,
>> not the standard's.
>
> The standard doesn't say anything to the issue I've shown.
>

The Standard defines the final results that must happen (or
possibilities that can happen in some cases).

If the implementation doesn't meet that result, it is non-conforming and
could be said to have implemented things "wrongly"

On 9/9/23 12:17 PM, Bonita Montero wrote:
> Am 09.09.2023 um 20:49 schrieb Chris M. Thomasson:
>
>> Huh? pthread_once totally applies here. Windows has futex like abilities.
>
> It doesn't matter what Posix or Win32 says. The standard should
> honour that static initialization might fail because of creating
> a synchronization primitive or synchronizing on them. The standard
> shoudln't require that this never fails.
>

Why?

Unless you can show that NO method can be created that meet the
requirements, using an insufficient method is just incorrect.

Since the use of a single synchronization primative meets the
requirement, (and a system that can't generate at least one is
insufficient to meet the standard), any system that can't meet the
requirement is just incorrect.

On 9/9/2023 11:00 AM, Pavel wrote:
> Chris M. Thomasson wrote:
>> On 9/8/2023 6:05 PM, Chris M. Thomasson wrote:
>>> On 9/8/2023 5:14 PM, Pavel wrote:
>>>> Chris M. Thomasson wrote:
>>>>> On 9/7/2023 1:00 PM, Bonita Montero wrote:
>>>>>> Am 07.09.2023 um 21:41 schrieb Chris M. Thomasson:
>>>>>>
>>>>>>> Yup. It uses address based hashing into the fixed mutex table.
>>>>>>
>>>>>> I guess that's not used at all in the runtimes.
>>>>>>
>>>>>
>>>>> Why not?
>>>>
>>>> I think it's not needed in general for static initialization purpose.
>>>>
>>>> This is because, if our design choice for our "C++ compiler" is to
>>>> use a dedicated mutex (or once_flag control) per a static variable
>>>> that requires dynamic initialization, nothing prevents our compiler
>>>> from allocating a static instance of such mutex or control next to
>>>> the static variable.
>>>>
>>>> Because mutex and once_flag can be constant-initialized (at least in
>>>> POSIX, notably Linux), the code that dynamically initializes a
>>>> variable can directly use the address of its respective
>>>> constant-initialized mutex or control, as in the following example:
>>>>
>>>> code in C++ source file:
>>>>
>>>> static type1 var1 = InitVar1();
>>>>
>>>> **pseudo-code** actually generated by the compiler:
>>>>
>>>> pthread_once_t __var1_once_control = PTHREAD_ONCE_INIT; /* generated
>>>> by the compiler when  */
>>>>
>>>> static type1 var1 = InitVar1(); /* this is compiled to,
>>>> **in pseudo-code**, to something like
>>>>
>>>>   pthread_once( [&var1]() { var1 = InitVar1(); } );
>>>> */
>>>
>>> pthread_once is perfectly fine. Just wondering, are you creating the
>>> POSIX impl directly here?
>>
>> Think of how you would directly implement pthread_once... There are
>> many different ways.
> You are correct, there are. Fortunately, I don't have to reinvent this
> particular wheel as the implementation source code is available for
> everyone to read. On Linux, Futex is a natural choice.
>
> Other platforms can have theirs. I did not program for Windows for long
> time but I would at least try to implement call_once with a critical
> section (whose creation, contrary to OP's insinuations, cannot fail
> since Windows Vista).

Windows has:

https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-initonceexecuteonce

https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-initonceinitialize

This is their part of their "futex" API:

https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitonaddress

Am 09.09.2023 um 22:37 schrieb Richard Damon:

> The Standard defines the final results that must happen
> (or possibilities that can happen in some cases).

The standards also should consider side effects as in this example
when a static initialization would fail because of a synchronization
error.

Am 09.09.2023 um 21:59 schrieb Chris M. Thomasson:

> On 9/9/2023 12:55 PM, Bonita Montero wrote:

>> F.e. because there's no more non-pageable memory for a semaphore.

> An address based hash into a table based approach works by creating
> everything up front. If this fails, then the user program logic is
> not even executed at all.

Do you want to follow in Amine's footsteps ?

Am 09.09.2023 um 22:41 schrieb Richard Damon:

> Why?

Because the standard should honour that kernel-synch might fail
on static initialization.

On 9/10/23 1:57 AM, Bonita Montero wrote:
> Am 09.09.2023 um 22:37 schrieb Richard Damon:
>
>> The Standard defines the final results that must happen
>> (or possibilities that can happen in some cases).
>
> The standards also should consider side effects as in this example
> when a static initialization would fail because of a synchronization
> error.
>
You don't seem to understand that sincd it CAN be done in a way that
always works, any method that doesn't always work is just WRONG and
non-conforming.

I guess you think that 1 + 1 must be allowed to be 1 in case of
"synchronization errors".

Static Initialization has DEFINED behavior, and that behavior must be
honored, and the implementation do what is need to make that happen.

Methods have been shown to do it (perhaps less performant than this is
some conditions), so it is possible, so you can't say the Standard is
asking for impossible behavior, thus any "optimizations" that don't meet
that defined behavior are just WRONG.

Saying something wrong must be made right is just WRONG, so you are
WRONG in your claim.

PERIOD.

Am 10.09.2023 um 15:51 schrieb Richard Damon:

> You don't seem to understand that sincd it CAN be done in a way that
> always works, ...

A standard shouldn't mandate that this never fails.

> Static Initialization has DEFINED behavior, and that behavior must be
> honored, and the implementation do what is need to make that happen.

Locking-errors while static initialitation are unspecified; whether
they might occur or not on a specific operating system doesn't matter.

10.09.2023 18:46 Bonita Montero kirjutas:
> Am 10.09.2023 um 15:51 schrieb Richard Damon:
>
>> You don't seem to understand that sincd it CAN be done in a way that
>> always works, ...
>
> A standard shouldn't mandate that this never fails.

So suppose the standard committee agrees with you and adds a sentence to
the standard:

Dynamic initialization of a non-local variable with static storage
duration can fail even if its initializing function does not throw, in
which case the behavior is ...undefined... / ..unspecified... /
....calling std::terminate() after unspecified time...

Which variant do you prefer? And how would this help the programmer who
needs to write programs in C++? Should they just avoid creating any
static variables at all, in order to not trigger this failure scenario?

Am 10.09.2023 um 18:08 schrieb Paavo Helde:

> Which variant do you prefer? And how would this help the programmer who
> needs to write programs in C++? Should they just avoid creating any
> static variables at all, in order to not trigger this failure scenario?

It should be handled like synchronization on a std::mutex,
which can fail with a system_error. If this would happen
the object would remain uninitialized.

On 9/10/23 8:46 AM, Bonita Montero wrote:
> Am 10.09.2023 um 15:51 schrieb Richard Damon:
>
>> You don't seem to understand that sincd it CAN be done in a way that
>> always works, ...
>
> A standard shouldn't mandate that this never fails.

You WANT a standard that says even if your program is written totally
correct, the implementation can decide that it will just make it run wrong?

>
>> Static Initialization has DEFINED behavior, and that behavior must be
>> honored, and the implementation do what is need to make that happen.
>
> Locking-errors while static initialitation are unspecified; whether
> they might occur or not on a specific operating system doesn't matter.
>

Since it has been shown that with a simpler locking method, you can
ALWAYS succeed (or die with a resource error before starting user code),
not meeting the requirement is just an error in the implementation.

PERIOD.

ANY operating system that can correctly run multi-threaded code can
handle that. If it can't, it can't actually handle multi-threaded code.

If an "optimization" can cause failures that can't otherwise occur, and
are not allowed by the standard, then that "optimization" isn't allowed
(except by switching to a non-conforming mode).

You don't seem to understand what a "Standard" is.

On 9/10/2023 1:58 AM, Bonita Montero wrote:
> Am 09.09.2023 um 21:59 schrieb Chris M. Thomasson:
>
>> On 9/9/2023 12:55 PM, Bonita Montero wrote:
>
>>> F.e. because there's no more non-pageable memory for a semaphore.
>
>> An address based hash into a table based approach works by creating
>> everything up front. If this fails, then the user program logic is
>> not even executed at all.
>
> Do you want to follow in Amine's footsteps ?

What do you mean by that comment?

On 9/10/2023 1:58 AM, Bonita Montero wrote:
> Am 09.09.2023 um 21:59 schrieb Chris M. Thomasson:
>
>> On 9/9/2023 12:55 PM, Bonita Montero wrote:
>
>>> F.e. because there's no more non-pageable memory for a semaphore.
>
>> An address based hash into a table based approach works by creating
>> everything up front. If this fails, then the user program logic is
>> not even executed at all.
>
> Do you want to follow in Amine's footsteps ?

Iirc, some systems have a large table of mutexes or semaphores created
up front in the kernel itself. They use them for contended futexes to
wait on. A futex is address based, and when they have to block that
index the address into said table. Have you ever used them before? Also,
think of Windows keyed events.

On 9/10/2023 1:59 AM, Bonita Montero wrote:
> Am 09.09.2023 um 22:41 schrieb Richard Damon:
>
>> Why?
>
> Because the standard should honour that kernel-synch might fail
> on static initialization.
>

Strange answer. Humm...

On 9/10/2023 1:59 AM, Bonita Montero wrote:
> Am 09.09.2023 um 22:41 schrieb Richard Damon:
>
>> Why?
>
> Because the standard should honour that kernel-synch might fail
> on static initialization.
>

So, are you suggesting that the C++ standard should be tightly
integrated with a given kernel impl? Humm... Strange. POSIX aside for a
moment...

On 9/10/2023 1:57 AM, Bonita Montero wrote:
> Am 09.09.2023 um 22:37 schrieb Richard Damon:
>
>> The Standard defines the final results that must happen
>> (or possibilities that can happen in some cases).
>
> The standards also should consider side effects as in this example
> when a static initialization would fail because of a synchronization
> error.
>

What error?

On 9/10/2023 9:15 AM, Bonita Montero wrote:
> Am 10.09.2023 um 18:08 schrieb Paavo Helde:
>
>> Which variant do you prefer? And how would this help the programmer
>> who needs to write programs in C++? Should they just avoid creating
>> any static variables at all, in order to not trigger this failure
>> scenario?
>
> It should be handled like synchronization on a std::mutex,
> which can fail with a system_error. If this would happen
> the object would remain uninitialized.
>

then what?

On 9/10/2023 9:32 AM, Richard Damon wrote:
> On 9/10/23 8:46 AM, Bonita Montero wrote:
>> Am 10.09.2023 um 15:51 schrieb Richard Damon:
>>
>>> You don't seem to understand that sincd it CAN be done in a way that
>>> always works, ...
>>
>> A standard shouldn't mandate that this never fails.
>
> You WANT a standard that says even if your program is written totally
> correct, the implementation can decide that it will just make it run wrong?
>
>>
>>> Static Initialization has DEFINED behavior, and that behavior must be
>>> honored, and the implementation do what is need to make that happen.
>>
>> Locking-errors while static initialitation are unspecified; whether
>> they might occur or not on a specific operating system doesn't matter.
>>
>
> Since it has been shown that with a simpler locking method, you can
> ALWAYS succeed (or die with a resource error before starting user code),
> not meeting the requirement is just an error in the implementation.
>
> PERIOD.
>
> ANY operating system that can correctly run multi-threaded code can
> handle that. If it can't, it can't actually handle multi-threaded code.
>
> If an "optimization" can cause failures that can't otherwise occur, and
> are not allowed by the standard, then that "optimization" isn't allowed
> (except by switching to a non-conforming mode).
>
>
> You don't seem to understand what a "Standard" is.

Ditto.