10.09.2023 19:15 Bonita Montero kirjutas:
> 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.

Meaning that a program can never access any static variable, because
accessing of an uninitialized object would be UB. Great job!

Chris M. Thomasson wrote:
> 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
Thanks, this does seem to be a simple user-friendly API that is most
appropriate to implement static initialization as in C++.

>
>
> This is their part of their "futex" API:
>
> https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitonaddress
>

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.
>
You did not show any issue, you just guessed what the implementation
could be and assumed there could be an issue.

After looking at InitOnceExecuteOnce API pointed out by Chris I think it
is very likely that your guess on implementation was wrong.

Richard Damon wrote:
> 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),
Actually, I think there should be always a better-performing method to
implement C++ static initialization than using windows or pthread mutex
-- e.g. using a specialized control like those used for call_once
implementation -- at least on UNIX or Windows.

This is because IMHO mutex API is a textbook case of feature bloat on
both platforms.

E.g. in standard UNIX (former POSIX), you can have recursive / robust /
shared / errorcheck mutex (not all mutually exclusive) and who knows
what else. pthread_mutex_lock shall be able to deal with either
combination and the feature-check code makes (at least the current)
implementation quite messy, with multiple dispatches on the same condition.

On Windows, the number of options is less; but, to compensate for that
:-), a mutex is always recursive plus wait functions have to know how to
deal with inter-process mutexes because any handle passed to them can
turn out to be of an inter-process mutex (or even not a mutex at all).
Therefore, I do not think their use for static initialization (that does
not require either recursive or inter-process lock) even could be optimal.

> 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 20:38 schrieb Paavo Helde:

> Meaning that a program can never access any static variable, because
> accessing of an uninitialized object would be UB. Great job!

Exactly the same thing can happen when locking a mutex,
which can also throw system_error. Do you think it is
unnecessary that a mutex can throw this exception ?

On 9/10/23 7:02 PM, Bonita Montero wrote:
> Am 10.09.2023 um 20:38 schrieb Paavo Helde:
>
>> Meaning that a program can never access any static variable, because
>> accessing of an uninitialized object would be UB. Great job!
>
> Exactly the same thing can happen when locking a mutex,
> which can also throw system_error. Do you think it is
> unnecessary that a mutex can throw this exception ?
>
>

Why does the Mutex throw "system_error" if it has already been
constructed and not misused?

On 9/10/2023 3:50 PM, Pavel wrote:
> Richard Damon wrote:
>> 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),
> Actually, I think there should be always a better-performing method to
> implement C++ static initialization than using windows or pthread mutex
> -- e.g. using a specialized control like those used for call_once
> implementation -- at least on UNIX or Windows.
>
> This is because IMHO mutex API is a textbook case of feature bloat on
> both platforms.
>
> E.g. in standard UNIX (former POSIX), you can have recursive / robust /
> shared / errorcheck mutex (not all mutually exclusive) and who knows
> what else. pthread_mutex_lock shall be able to deal with either
> combination and the feature-check code makes (at least the current)
> implementation quite messy, with multiple dispatches on the same condition.
>
> On Windows, the number of options is less; but, to compensate for that
> :-), a mutex is always recursive plus wait functions have to know how to
> deal with inter-process mutexes because any handle passed to them can
> turn out to be of an inter-process mutex (or even not a mutex at all).
> Therefore, I do not think their use for static initialization (that does
> not require either recursive or inter-process lock) even could be optimal.

I might be missing your point here. Humm... Even though POSIX has all of
these different types of mutexs, we can use them by organization. So,
wrt windows, an intra-process mutex can be a CRITICAL_SECTION. Or an
inter-process as a mutex HANDLE.

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

Wrt the inter-process route we may need to deal with WAIT_ABANDONED, or
EOWNERDEAD wrt POSIX. So we create different types:

struct intra_process_mutex
{ CRITICAL_SECTION m_os_lock;
};

struct inter_process_mutex
{ HANDLE m_os_lock;
};

struct inter_process_mutex_robust
{ HANDLE m_os_lock;
};

These simple types can be rather easy to reason about. Wrt POSIX, the
different types would be:

struct intra_process_mutex
{ pthread_mutex_t m_os_lock;
};

struct inter_process_mutex
{ pthread_mutex_t m_os_lock;
};

struct inter_process_mutex_robust
{ pthread_mutex_t m_os_lock;
};

The point is trying to organize things a bit here.

Sound somewhat decent?

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

On 9/10/2023 7:02 PM, Bonita Montero wrote:
> Am 10.09.2023 um 20:38 schrieb Paavo Helde:
>
>> Meaning that a program can never access any static variable, because
>> accessing of an uninitialized object would be UB. Great job!
>
> Exactly the same thing can happen when locking a mutex,
> which can also throw system_error. Do you think it is
> unnecessary that a mutex can throw this exception ?
>
>

Read about what can happen to the windows "futex" during periods of hard
stress on the OS, low memory, most likely very low non-paged memory,
"almost" getting to a blue screen type of shit! damn, anyway:
___________________________
Note WaitOnAddress is guaranteed to return when the address is
signaled, but it is also allowed to return for other reasons. For this
reason, after WaitOnAddress returns the caller should compare the new
value with the original undesired value to confirm that the value has
actually changed. For example, the following circumstances can result in
waking the thread early:
Low memory conditions
A previous wake on the same address was abandoned
Executing code on a checked build of the operating system
___________________________

Take special note "Low memory conditions"...

I bet their call once logic is using their "futex" logic. Humm... Anyone
have any insight into the windows possible internal impl? I want to read
sysinternals magazine again... I used to have it delivered to my house. ;^)

https://learn.microsoft.com/en-us/sysinternals/

;^)

Am 10.09.2023 um 20:38 schrieb Paavo Helde:

> Meaning that a program can never access any static variable, because
> accessing of an uninitialized object would be UB. Great job!

That's the same as when the static object's constructor throws,
i.e. the object will get another try if you get again to the
initialization. And if an exception is thrown the context of
the definition is left to the next exception handler that you
won't operate on a non initialized object.
I don't see where's the problem here.

Am 11.09.2023 um 15:44 schrieb Bonita Montero:

> That's the same as when the static object's constructor throws,
> i.e. the object will get another try if you get again to the
> initialization. And if an exception is thrown the context of
> the definition is left to the next exception handler that you
> won't operate on a non initialized object.
> I don't see where's the problem here.

Look at this code:

#include <iostream>

using namespace std;

int main()
{ struct WillReInit
{
WillReInit()
{
throw "hello world";
}
};
for( ; ; )
try
{
static WillReInit wi;
}
catch( char const *str )
{
cout << str << endl;
}
}

Things would be similar if the synchronization would throw, i.e. wri
would be initialized over and over. So there won't be any accessible
uninitialized object.

Am 10.09.2023 um 20:12 schrieb Chris M. Thomasson:

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

Not more than it is integrated to the operating system through
throwing system_error, therby having an operating dependent
error code which is translated by the operating system (inter-
nally through strerror() or FormatMessage()).
So it would be most appropriate to throw system_error with an
operating system dependent error code and system_category as
the translator - just like std::mutex does.

11.09.2023 16:49 Bonita Montero kirjutas:
> Am 11.09.2023 um 15:44 schrieb Bonita Montero:
>
>> That's the same as when the static object's constructor throws,
>> i.e. the object will get another try if you get again to the
>> initialization. And if an exception is thrown the context of
>> the definition is left to the next exception handler that you
>> won't operate on a non initialized object.
>> I don't see where's the problem here.
>
> Look at this code:
>
> #include <iostream>
>
> using namespace std;
>
> int main()
> {
>     struct WillReInit
>     {
>         WillReInit()
>         {
>             throw "hello world";
>         }
>     };
>     for( ; ; )
>         try
>         {
>             static WillReInit wi;
>         }
>         catch( char const *str )
>         {
>             cout << str << endl;
>         }
> }
>
>
> Things would be similar if the synchronization would throw, i.e. wri
> would be initialized over and over. So there won't be any accessible
> uninitialized object.

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

Even for local objects, what's the point? If the issue could be resolved
by simply retrying the operation, the C++ implementation could easily do
the same internally and avoid the issue. If the issue cannot be resolved
by a simple retry, then what code should a programmer write, to get the
static initialized? Especially considering that the issue is
non-reproducible and thus cannot be played out or tested. Writing
untestable code to work around non-existing errors is not a healthy way
to spend ones time IMO.

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

Then you misunderstood me and talked nonsense. Of course I didn't talk
about global objects, because exceptions make no sense because they
can't be caught in any functional context. It goes without saying.

> Even for local objects, what's the point?
> If the issue could be resolved by simply retrying the operation, ...

If you think spinning would make sense, then you could handle most
system_error errors like that. But that's not how it's designed.

> Especially considering that the issue is non-reproducible and thus
> cannot be played out or tested.

A failing mutex isn't reproducible either; nevertheless there are
system_error exceptions which could be thrown while synchonizing.

On 9/11/2023 7:29 AM, Bonita Montero wrote:
> Am 10.09.2023 um 20:12 schrieb Chris M. Thomasson:
>
>> So, are you suggesting that the C++ standard should be tightly
>> integrated with a given kernel impl? Humm... Strange. POSIX
>> aside for a moment...
>
>
> Not more than it is integrated to the operating system through
> throwing system_error, therby having an operating dependent
> error code which is translated by the operating system (inter-
> nally through strerror() or FormatMessage()).
> So it would be most appropriate to throw system_error with an
> operating system dependent error code and system_category as
> the translator - just like std::mutex does.
>

What if somebody writing C++ wants to be abstract and try to avoid a
particular systems idiosyncrasies?

if std::mutex throws, then shit hit the fan. Not good.

Am 11.09.2023 um 21:41 schrieb Chris M. Thomasson:

> What if somebody writing C++ wants to be abstract
> and try to avoid a particular systems idiosyncrasies?

Then he would have to ignore specific error codes and
just take the what() in the system_error object.

Chris M. Thomasson wrote:
> On 9/10/2023 3:50 PM, Pavel wrote:
>> Richard Damon wrote:
>>> 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),
>> Actually, I think there should be always a better-performing method to
>> implement C++ static initialization than using windows or pthread
>> mutex -- e.g. using a specialized control like those used for
>> call_once implementation -- at least on UNIX or Windows.
>>
>> This is because IMHO mutex API is a textbook case of feature bloat on
>> both platforms.
>>
>> E.g. in standard UNIX (former POSIX), you can have recursive / robust
>> / shared / errorcheck mutex (not all mutually exclusive) and who knows
>> what else. pthread_mutex_lock shall be able to deal with either
>> combination and the feature-check code makes (at least the current)
>> implementation quite messy, with multiple dispatches on the same
>> condition.
>>
>> On Windows, the number of options is less; but, to compensate for that
>> :-), a mutex is always recursive plus wait functions have to know how
>> to deal with inter-process mutexes because any handle passed to them
>> can turn out to be of an inter-process mutex (or even not a mutex at
>> all). Therefore, I do not think their use for static initialization
>> (that does not require either recursive or inter-process lock) even
>> could be optimal.
>
> I might be missing your point here. Humm... Even though POSIX has all of
> these different types of mutexs, we can use them by organization.
The point is that, even assuming that all types of mutices are very well
organized in the implementation, some dispatch of control still has to
occur when one calls "pthread_mutex_lock" because it is a single entry
point for locking a mutex with any combination of features. Given that
locking of a non-contended mutex is supposed to be (and in fact is, on
current Linux) very cheap (but not necessarily same-cheap if the mutex
is recursive :-) ), the relative cost of this dispatch is not guaranteed
to be negligible (even if that dispatch is implemented via a single
extra level of indirection).

Further, I am unsure if these features actually *can* be very well
organized because not all features of mutices are mutually exclusive (no
pun intended) so a single extra level of indirection might not be enugh.
As an example, mutexattr type can be one of

PTHREAD_MUTEX_NORMAL PTHREAD_MUTEX_ERRORCHECK PTHREAD_MUTEX_RECURSIVE
PTHREAD_MUTEX_DEFAULT

but each of these can be additionally either robust or non-robust (and,
pthread_mutex_lock is supposed to behave differently for some
combinations of type and robustness). Unless of course we dispatch to a
cartesian product of options (which is not impossible, but see below).

And, lastly, the above are all hypotheticals and the actual code (see
e.g. https://codebrowser.dev/glibc/glibc/nptl/pthread_mutex_lock.c.html
) is slightly messier than the best organized implementation possible.
From practical perspective, I would expect that someone implementing a
thread-safe static initialization in a C++ compiler has their mouth full
with the tasks other than improving the existing pthread_mutex (or
pthread_once) implementation as a distraction; at most (I would
speculate), they would take a quick (~5 min) look into the API and the
available code of the existing established synchronization primitives
and decide which one is likely to better fit their spec and be faster
as-is to use to implement that pesky initialization spec. In this
scenario, I would guess that pthread_once_t would win the beauty contest
and get selected.

And, sure enough, (likely due to no feature bloat) the *existing*
pthread_once implementation code is much cleaner (see
https://codebrowser.dev/glibc/glibc/nptl/pthread_once.c.html) and at
first glance should be measurably faster.

I guess, instead of guessing, (no pun untended again), we could just
disassemble some static initialization and see how it's done in, say,
gcc. Maybe later...

> So,
> wrt windows, an intra-process mutex can be a CRITICAL_SECTION. Or an
> inter-process as a mutex HANDLE.
>
> https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createmutexexa
>
>
> Wrt the inter-process route we may need to deal with WAIT_ABANDONED, or
> EOWNERDEAD wrt POSIX. So we create different types:
>
>
> struct intra_process_mutex
> {
>     CRITICAL_SECTION m_os_lock;
> };
>
>
> struct inter_process_mutex
> {
>     HANDLE m_os_lock;
> };
>
> struct inter_process_mutex_robust
> {
>     HANDLE m_os_lock;
> };
>
>
>
> These simple types can be rather easy to reason about. Wrt POSIX, the
> different types would be:
>
>
> struct intra_process_mutex
> {
>     pthread_mutex_t m_os_lock;
> };
>
>
> struct inter_process_mutex
> {
>     pthread_mutex_t m_os_lock;
> };
>
> struct inter_process_mutex_robust
> {
>     pthread_mutex_t m_os_lock;
> };
>
>
> The point is trying to organize things a bit here.
>
> Sound somewhat decent?
>
>
>>
>>> 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.
>>
>

On 9/11/2023 7:28 PM, Bonita Montero wrote:
> Am 11.09.2023 um 21:41 schrieb Chris M. Thomasson:
>
>> What if somebody writing C++ wants to be abstract
>> and try to avoid a  particular systems idiosyncrasies?
>
> Then he would have to ignore specific error codes and
> just take the what() in the system_error object.
>

what() = shit hit the fan...

Am 12.09.2023 um 07:39 schrieb Chris M. Thomasson:

> On 9/11/2023 7:28 PM, Bonita Montero wrote:

>> Then he would have to ignore specific error codes and
>> just take the what() in the system_error object.

> what() = shit hit the fan...

You seem to be psychotic, but I'll describe it anyway. If you have
a system_error and it is created with a system_category the error
code is converted through streror() (or the thread -safe variant)
on Posix and with FormatMessage() in Windows.
With MSVC there was a bug which I filed in forum for MSVC that
system_category() does not honor the current threads's locale
when translating the error code with FormatMessage(). They
said they'll fix that and actually it was fixed with the next
update.

On 9/12/2023 2:44 AM, Bonita Montero wrote:
> Am 12.09.2023 um 07:39 schrieb Chris M. Thomasson:
>
>> On 9/11/2023 7:28 PM, Bonita Montero wrote:
>
>>> Then he would have to ignore specific error codes and
>>> just take the what() in the system_error object.
>
>> what() = shit hit the fan...
>
> You seem to be psychotic, but I'll describe it anyway.

If a static initialization fails, things have gone horribly wrong.
What's your big beef with static initialization?

> If you have
> a system_error and it is created with a system_category the error
> code is converted through streror() (or the thread -safe variant)
> on Posix and with FormatMessage() in Windows.
> With MSVC there was a bug which I filed in forum for MSVC that
> system_category() does not honor the current threads's locale
> when translating the error code with FormatMessage(). They
> said they'll fix that and actually it was fixed with the next
> update.
>

Am 12.09.2023 um 20:33 schrieb Chris M. Thomasson:
> On 9/12/2023 2:44 AM, Bonita Montero wrote:
>> Am 12.09.2023 um 07:39 schrieb Chris M. Thomasson:
>>
>>> On 9/11/2023 7:28 PM, Bonita Montero wrote:
>>
>>>> Then he would have to ignore specific error codes and
>>>> just take the what() in the system_error object.
>>
>>> what() = shit hit the fan...
>>
>> You seem to be psychotic, but I'll describe it anyway.
>
> If a static initialization fails, things have gone horribly wrong.
> What's your big beef with static initialization?

At this point we weren't talking about static initialization but about
the properties of system_error. But static initialization is less likely
to go wrong because of a synchronization error but more likely because
the constructor of the static object throws. As I've shown with my code
in this thread the object is left uninitialized then and if the code
reaches the initialization again it gets another chance.

On 9/12/2023 11:43 AM, Bonita Montero wrote:
> Am 12.09.2023 um 20:33 schrieb Chris M. Thomasson:
>> On 9/12/2023 2:44 AM, Bonita Montero wrote:
>>> Am 12.09.2023 um 07:39 schrieb Chris M. Thomasson:
>>>
>>>> On 9/11/2023 7:28 PM, Bonita Montero wrote:
>>>
>>>>> Then he would have to ignore specific error codes and
>>>>> just take the what() in the system_error object.
>>>
>>>> what() = shit hit the fan...
>>>
>>> You seem to be psychotic, but I'll describe it anyway.
>>
>> If a static initialization fails, things have gone horribly wrong.
>> What's your big beef with static initialization?
>
> At this point we weren't talking about static initialization but about
> the properties of system_error. But static initialization is less likely
> to go wrong because of a synchronization error but more likely because
> the constructor of the static object throws. As I've shown with my code
> in this thread the object is left uninitialized then and if the code
> reaches the initialization again it gets another chance.
>

You mean where you wrote:

"The mutex constructor
is noexcept, so mutexes always must be created on their first use."

Well... Why do you state that mutexes must always be created on their
first use? Hummm. Just because you say so, does not make it true at all.

On 9/12/2023 3:55 PM, Chris M. Thomasson wrote:
> On 9/12/2023 11:43 AM, Bonita Montero wrote:
>> Am 12.09.2023 um 20:33 schrieb Chris M. Thomasson:
>>> On 9/12/2023 2:44 AM, Bonita Montero wrote:
>>>> Am 12.09.2023 um 07:39 schrieb Chris M. Thomasson:
>>>>
>>>>> On 9/11/2023 7:28 PM, Bonita Montero wrote:
>>>>
>>>>>> Then he would have to ignore specific error codes and
>>>>>> just take the what() in the system_error object.
>>>>
>>>>> what() = shit hit the fan...
>>>>
>>>> You seem to be psychotic, but I'll describe it anyway.
>>>
>>> If a static initialization fails, things have gone horribly wrong.
>>> What's your big beef with static initialization?
>>
>> At this point we weren't talking about static initialization but about
>> the properties of system_error. But static initialization is less likely
>> to go wrong because of a synchronization error but more likely because
>> the constructor of the static object throws. As I've shown with my code
>> in this thread the object is left uninitialized then and if the code
>> reaches the initialization again it gets another chance.
>>
>
> You mean where you wrote:
>
> "The mutex constructor
> is noexcept, so mutexes always must be created on their first use."
>
> Well... Why do you state that mutexes must always be created on their
> first use? Hummm. Just because you say so, does not make it true at all.

The subject is about static initialization, and the sync that the impl
uses to get that does does not have to follow your rules at all.

Am 13.09.2023 um 00:55 schrieb Chris M. Thomasson:

> Well... Why do you state that mutexes must always be created on their
> first use? Hummm. Just because you say so, does not make it true at all.

Of course, because the mutex constructor is noexcept. The interesting
thing is that the situation can arise where several threads simultan-
eously try to create the binary semaphore associated with the mutex
and only one ultimately assigns this semaphore to the mutex. And if
the other threads notice this afterwards, they have to return the
semaphore to the kernel. Since the mutex constructor is noexcept
there is no other way for an implementation to handle this.

On 9/13/2023 2:53 AM, Bonita Montero wrote:
> Am 13.09.2023 um 00:55 schrieb Chris M. Thomasson:
>
>> Well... Why do you state that mutexes must always be created on their
>> first use? Hummm. Just because you say so, does not make it true at all.
>
> Of course, because the mutex constructor is noexcept. The interesting
> thing is that the situation can arise where several threads simultan-
> eously try to create the binary semaphore associated with the mutex
> and only one ultimately assigns this semaphore to the mutex. And if
> the other threads notice this afterwards, they have to return the
> semaphore to the kernel. Since the mutex constructor is noexcept
> there is no other way for an implementation to handle this.
>

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.

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, where the
mutex is used only once by the thread which initializes the
object and there's not much likehood of contention and even
if, this contention happens only once per competing thread ?