Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 14.09.2023 um 01:23 schrieb Chris M. Thomasson:
>
>> How do you think futexes work when they are completely addressed based?
>> Nothing to create. I guess you are not that familiar with them. So be it.
>
>Why should a futex be uses on static initializaton,

Because throwing an error on static initialization is a stupid idea.

Am 14.09.2023 um 16:37 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 14.09.2023 um 01:23 schrieb Chris M. Thomasson:
>>
>>> How do you think futexes work when they are completely addressed based?
>>> Nothing to create. I guess you are not that familiar with them. So be it.
>>
>> Why should a futex be uses on static initializaton,

> Because throwing an error on static initialization is a stupid idea.

The objection doesn't make sense here, but perhaps elsewhere in the
thread.
The constructor that initializes statically can throw an exception
itself. If this takes place in the functional context, it can also
be caught and the object is attempted to be created in the next run.
Likewise, synchronization could throw an exception during static
initialization and the way it is handled does not change compared
to the case where the constructor itself is.

On 9/14/2023 7:37 AM, Scott Lurndal wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 14.09.2023 um 01:23 schrieb Chris M. Thomasson:
>>
>>> How do you think futexes work when they are completely addressed based?
>>> Nothing to create. I guess you are not that familiar with them. So be it.
>>
>> Why should a futex be uses on static initializaton,
>
> Because throwing an error on static initialization is a stupid idea.

Ding! Agreed.

Am 16.09.2023 um 06:39 schrieb Chris M. Thomasson:

>> Because throwing an error on static initialization is a stupid idea.

> Ding! Agreed.

Why ? If synchronization through a std::mutex could fail the
synchronization part of static initialization could also fail.
So it would be nice if an appropriate exception would be thrown
in this case.

On 9/16/23 1:03 AM, Bonita Montero wrote:
> Am 16.09.2023 um 06:39 schrieb Chris M. Thomasson:
>
>>> Because throwing an error on static initialization is a stupid idea.
>
>> Ding! Agreed.
>
> Why ? If synchronization through a std::mutex could fail the
> synchronization part of static initialization could also fail.
> So it would be nice if an appropriate exception would be thrown
> in this case.
>

Because the synchronization (which doesn't need to be through a
std::mutex) isn't allowed to fail.

The C++ Standard doesn't allow the implementation to use a method to
synchronize that can fail. At best, the implementation needs to generate
code that handles the error and retries.

Am 16.09.2023 um 14:41 schrieb Richard Damon:

> Because the synchronization (which doesn't need to be through
> a std::mutex) isn't allowed to fail.

This is a requirement that could just as pointlessly be placed
on a mutex.

> The C++ Standard doesn't allow the implementation to use a
> method to synchronize that can fail. At best, the implementation
> needs to generate code that handles the error and retries.

There is actually no need for this property if synchronization
elsewhere fails with an exception. The most appropriate solution
would be to have a system_error on a synchronization exception
as with a mutex and this exception would have the same effect
as if the constructor of the object throws.

Am 11.09.2023 um 17:20 schrieb Paavo Helde:

> Good, finally some code! Alas, this is not very relevant as it demoes a
> local static object, my post which you replied to started with "Dynamic
> initialization of a non-local variable with static storage duration..."

One thing just occurred to me: with global objects, the initialization
could theoretically be carried out with a delay, and this would then
happen in the functional context. This would primarily solve the static
initialization order fiasco. Maybe C++ could introduce an [[attribute]]
for that for global objects.

Bonita Montero wrote:
> Am 16.09.2023 um 14:41 schrieb Richard Damon:
>
>> Because the synchronization (which doesn't need to be through
>> a std::mutex) isn't allowed to fail.
>
> This is a requirement that could just as pointlessly be placed
> on a mutex.
Locking mutex is allowed, but not required, to fail.

Nothing in the C++ standard prevents the implementation of the static
initialization from relying on a mutex of type that cannot fail.

Moreover, nothing in the C++ standard prevents the implementation of the
static initialization from not relying on mutex.

Therefore, the C++ standard is correct to not define any special
protocol for processing synchronization exception during static
initialization.
>
>> The C++ Standard doesn't allow the implementation to use a
>> method to synchronize that can fail. At best, the implementation
>> needs to generate code that handles the error and retries.
>
> There is actually no need for this property if synchronization
> elsewhere fails with an exception. The most appropriate solution
> would be to have a system_error on a synchronization exception
> as with a mutex and this exception would have the same effect
> as if the constructor of the object throws.
>

Am 16.09.2023 um 19:23 schrieb Pavel:

> Locking mutex is allowed, but not required, to fail.

Yes, but you have to expect an exception
and the implementation can throw it.

> Nothing in the C++ standard prevents the implementation of the static
> initialization from relying on a mutex of type that cannot fail.

But C++ should take platforms into account where this can happen.

> Moreover, nothing in the C++ standard prevents the implementation
> of the static initialization from not relying on mutex.

It doesn't matter whether it's called mutex or something
else. Ultimately, resource allocation and synchronization
can theoretically fail.

> Therefore, the C++ standard is correct to not define any special
> protocol for processing synchronization exception during static
> initialization.

Absolutely not because there are different platforms.

On 9/16/2023 10:38 AM, Bonita Montero wrote:
> Am 16.09.2023 um 19:23 schrieb Pavel:
>
>> Locking mutex is allowed, but not required, to fail.
>
> Yes, but you have to expect an exception
> and the implementation can throw it.
>
>> Nothing in the C++ standard prevents the implementation of the static
>> initialization from relying on a mutex of type that cannot fail.
>
> But C++ should take platforms into account where this can happen.
>
>> Moreover, nothing in the C++ standard prevents the implementation
>> of the static initialization from not relying on mutex.
>
> It doesn't matter whether it's called mutex or something
> else. Ultimately, resource allocation and synchronization
> can  theoretically fail.

Well, there are many different methods. For instance, one way is that
all of the resource allocation can be created in the kernel wrt futexes
up front. OS startup, or even create a futex sync table on a per-process
basis. They are address based. So, if you have a pointer to some data,
alignment issues aside for a moment, you can use it with a futex.

Now synchronization failing is a horrible bug in the sync algorithm
itself. How do you envision synchronization failing? The failure to
create a std::mutex is one thing, a std::mutex failing to lock is a
completely different issue.

Also, why do you seem to think that an impl _must_ create a std::mutex
for each static initialization?

By the way, std::mutex can be based on a futex. So, the mutex does not
need to create anything wrt kernel resources. It can be based on an
std::uintptr_t. No need to create any kernel sync objects. Did you read
about the way Windows does futexes? :^)

>
>> Therefore, the C++ standard is correct to not define any special
>> protocol for processing synchronization exception during static
>> initialization.
>
> Absolutely not because there are different platforms.
>

Bonita Montero wrote:
> Am 16.09.2023 um 19:23 schrieb Pavel:
>
>> Locking mutex is allowed, but not required, to fail.
>
> Yes, but you have to expect an exception
> and the implementation can throw it.
>
>> Nothing in the C++ standard prevents the implementation of the static
>> initialization from relying on a mutex of type that cannot fail.
>
> But C++ should take platforms into account where this can happen.
>
>> Moreover, nothing in the C++ standard prevents the implementation
>> of the static initialization from not relying on mutex.
>
> It doesn't matter whether it's called mutex or something
> else. Ultimately, resource allocation
For many synchronization primitives, resource allocation for static
instances of the primitives can be done entirely at the time when
program is loaded to memory. Static initialization can be done with only
such instances. This static constant initialization of such primitives
cannot fail. Incidentally, intra-process POSIX mutexes can be
initialized like this, e.g.:

static pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;

And this cannot fail, either theoretically or practically.

or, a non-mutex primitive can be initialized like this

static pthread_once_t once_control = PTHREAD_ONCE_INIT;

And this cannot fail, either theoretically or practically.

> and synchronization

pthread_once on properly initialized once control cannot fail, either
theoretically or practically (assuming the function it calls does not
fail -- but that case is covered by the C++ standard).

> can  theoretically fail.

No.

>
>> Therefore, the C++ standard is correct to not define any special
>> protocol for processing synchronization exception during static
>> initialization.
>
> Absolutely not because there are different platforms.

There have only been platforms where C++ Standard could not be
implemented. EPOC32 / Symbian comes to mind. This is old news. It is not
the goal of the standard to be implementable at any platform and, if it
were, it would not be a realistic one.

Am 16.09.2023 um 20:46 schrieb Chris M. Thomasson:

> Well, there are many different methods. ...

But all acceptable include allocating a resource whose
allocation might fail.

> Now synchronization failing is a horrible bug in the sync algorithm
> itself. ...

It doesn't matter how this happens because sth. like
WaitForSingleObject() has an error code you have to honor.

> By the way, std::mutex can be based on a futex. So, the mutex does not
> need to create anything wrt kernel resources. ...

A futex also has kernel resources, it's just a semaphore which is
trapped by the MMU, which is a faster way to get into the kernel.

Am 16.09.2023 um 22:34 schrieb Pavel:

> For many synchronization primitives, resource allocation for static
> instances of the primitives can be done entirely at the time when
> program is loaded to memory. Static initialization can be done with
> only such instances. This static constant initialization of such
> primitives cannot fail. Incidentally, intra-process POSIX mutexes
> can be initialized like this, e.g.:

As I've shown with my program MSVC, libstdc++ (g++) and libc++ (clang++)
have per object mutexes. And the runtime should be able to support that
to have maximum parallelism while initializing. So the standard should
support that.

On 9/16/23 11:57 PM, Bonita Montero wrote:
> Am 16.09.2023 um 22:34 schrieb Pavel:
>
>> For many synchronization primitives, resource allocation for static
>> instances of the primitives can be done entirely at the time when
>> program is loaded to memory. Static initialization can be done with
>> only such instances. This static constant initialization of such
>> primitives cannot fail. Incidentally, intra-process POSIX mutexes
>> can be initialized like this, e.g.:
>
> As I've shown with my program MSVC, libstdc++ (g++) and libc++ (clang++)
> have per object mutexes. And the runtime should be able to support that
> to have maximum parallelism while initializing. So the standard should
> support that.
>
>

Why?

Do you REALLY want you programs to be able to die for undetectable reasons?

It would be ok to default to such a method, as long as there is a
fall-back to a fallback that always works.

Microsoft has a history of not being fully conforming on aspects, so
just because Microsoft does it doesn't make it right.

You just don't seem to understand the concept of being able to expect
that valid code should just work.

Am 17.09.2023 um 16:46 schrieb Richard Damon:

> You just don't seem to understand the concept of being able to
> expect that valid code should just work.

You simply understand the problem. Specifying exceptions on
static local variables initialization would make software more
reliable, not less.

Bonita Montero wrote:
> Am 16.09.2023 um 22:34 schrieb Pavel:
>
>> For many synchronization primitives, resource allocation for static
>> instances of the primitives can be done entirely at the time when
>> program is loaded to memory. Static initialization can be done with
>> only such instances. This static constant initialization of such
>> primitives cannot fail. Incidentally, intra-process POSIX mutexes
>> can be initialized like this, e.g.:
>
> As I've shown with my program MSVC, libstdc++ (g++) and libc++ (clang++)
> have per object mutexes.
No your program does not show this. All it alludes to is that there is
no single static synchronization primitive instance for all statically
initialized variables.

In particular, your program did not show that mutexes are used at all
for static initialization on any of those platforms.

Even if you proved mutexes are used (which you did not), they still
could be used in a way that they cannot fail as shown in my example.

> And the runtime should be able to support that
> to have maximum parallelism while initializing. So the standard should
> support that.
>
>

On 9/17/23 12:02 PM, Bonita Montero wrote:
> Am 17.09.2023 um 16:46 schrieb Richard Damon:
>
>> You just don't seem to understand the concept of being able to
>> expect that valid code should just work.
>
> You simply understand the problem. Specifying exceptions on
> static local variables initialization would make software more
> reliable, not less.

No, since teh ONLY exceptions that are ALLOWED for static local
variables, are those actually thrown by the constructor itself, and NOT
the required "syncronization" (and for file scope variable, such
exceptions are fatal) giving conforming implementations the latitude to
just FAIL is a LOSS in reliablity.

How is allowing a program to just fail to run, without an ability to do
anything about it, make it more reliable?

All you are arguing is that non-conforming implementations should be
allowed to claim conformance.

By the Standard, static initialization isn't allowed to have a
"syncronization issue", the implementation MUST be able to make it work.
If it can't, it just isn't conforming.

It is possible to do it on any operating system that can actually handle
multiple threads reliably, so any optimization that gives an incorrect
result is just WRONG.

It is just as wrong as an optimization that "optimizes" 1+1 and gives
the value of 1 sometimes.

Am 17.09.2023 um 19:40 schrieb Richard Damon:

> By the Standard, static initialization isn't allowed to have a
> "syncronization issue", ...

If you implement it that way like MSVC, libc++ and libstdc++ with
a mutex per object synchronization can fail. And the standard should
define what happens then.

Am 17.09.2023 um 19:37 schrieb Pavel:

> Bonita Montero wrote:
>> As I've shown with my program MSVC, libstdc++ (g++) and libc++ (clang++)
>> have per object mutexes.

> No your program does not show this. ...

Of course I show this. I've got a generic lambda and each thread
gets its own instantiation of the calling operator of that lambda,
thereby having _individual_ static objects per calling operator.

On 9/16/2023 8:45 PM, Bonita Montero wrote:
> Am 16.09.2023 um 20:46 schrieb Chris M. Thomasson:
>
>> Well, there are many different methods. ...
>
> But all acceptable include allocating a resource whose
> allocation might fail.
>
>> Now synchronization failing is a horrible bug in the sync algorithm
>> itself. ...
>
> It doesn't matter how this happens because sth. like
> WaitForSingleObject() has an error code you have to honor.

Getting WAIT_FAILED means something really bad has hit the fan.
WAIT_ABANDONED is fine and can be handled, akin to EOWNERDEAD. This is
for inter-process robust sync.

>> By the way, std::mutex can be based on a futex. So, the mutex does not
>> need to create anything wrt kernel resources. ...
>
> A futex also has kernel resources, it's just a semaphore which is
> trapped by the MMU, which is a faster way to get into the kernel.
>
A futex does not need to create new kernel resources on demand. They are
already there.

On 9/17/23 2:04 PM, Bonita Montero wrote:
> Am 17.09.2023 um 19:40 schrieb Richard Damon:
>
>> By the Standard, static initialization isn't allowed to have a
>> "syncronization issue", ...
>
> If you implement it that way like MSVC, libc++ and libstdc++ with
> a mutex per object synchronization can fail. And the standard should
> define what happens then.
>

You have it backwards. If the mutex object actually CAN fail, than any
implementation that uses them, and don'y handle the failure, is incorrect.

The Standard defines What Must Happen, if it doesn't, the implementation
in non-conforming.

On 9/17/2023 11:06 AM, Bonita Montero wrote:
> Am 17.09.2023 um 19:37 schrieb Pavel:
>
>> Bonita Montero wrote:
>>> As I've shown with my program MSVC, libstdc++ (g++) and libc++ (clang++)
>>> have per object mutexes.
>
>> No your program does not show this. ...
>
> Of course I show this. I've got a generic lambda and each thread
> gets its own instantiation of the calling operator of that lambda,
> thereby having _individual_ static objects per calling operator.
>

Sigh.

On 9/17/2023 11:04 AM, Bonita Montero wrote:
> Am 17.09.2023 um 19:40 schrieb Richard Damon:
>
>> By the Standard, static initialization isn't allowed to have a
>> "syncronization issue", ...
>
> If you implement it that way like MSVC, libc++ and libstdc++ with
> a mutex per object synchronization can fail. And the standard should
> define what happens then.
>

Sigh.

Am 17.09.2023 um 20:25 schrieb Chris M. Thomasson:

> Getting WAIT_FAILED means something really bad has hit the fan.
> WAIT_ABANDONED is fine and can be handled, akin to EOWNERDEAD.
> This is for inter-process robust sync.

It's unspecified why this happens.

> A futex does not need to create new kernel resources on demand.
> They are already there.

Read the Linux futex paper. The page which holds the futex is locked
and there's a wating queue for contenders inside the kernel.

Am 17.09.2023 um 20:26 schrieb Richard Damon:

> You have it backwards. If the mutex object actually CAN fail, than any
> implementation that uses them, and don'y handle the failure, is incorrect.

The standard should allow an implementation that fails and have
a way to handle that; a system_error would be the most appropiate
way.