On 9/24/2023 4:55 AM, Bonita Montero wrote:
> Am 24.09.2023 um 13:50 schrieb Michael S:
>
>> As to what is professional and what not, it's matter of opinion
>> and circumstances. ...
>
> The implementation can't estimate how long a static initialization
> takes. If it takes a longer time spinning would be a real problem.
> Yielding would also be not ok because the contenders may wait longer
> than necessary under load conditions or if not, may actually spin
> and consume unecessary power. So a semaphore is the only solution
> that makes sense.
>

You are all over the place. Sigh. Sorry, Bonita but you are fired from
the team.

On 9/24/2023 10:00 AM, Pavel wrote:
> Chris M. Thomasson wrote:
>> On 9/23/2023 2:58 PM, Pavel wrote:
>>> Bonita Montero wrote:
>>>> Am 23.09.2023 um 04:50 schrieb Pavel:
>>>>
>>>>> for some mutex it may fail, for some not. C++ standard never says
>>>>> that std::mutex can fail. ...
>>>>
>>>> std::mutex::lock() can throw a system_error.
>>> Wrong. The standard says that lock can throw while discussing general
>>> requirements for all types of mutices (mutex, recursive_mutex,
>>> timed_mutex, recursive_timed_mutex, shared_mutex, and
>>> shared_timed_mutex). Then, when discussing specific mutices, the
>>> standard says that recursive_mutex, recursive_timed_mutex and any of
>>> the shared mutices can throw system_error). About std::mutex the
>>> standard says no such thing.
>>>
>>> The only mentioning of an error for std::mutex is in a non-normative
>>> note that explains: "If the
>>> implementation can detect the deadlock, a
>>> resource_deadlock_would_occur error condition might be observed". We
>>> knew that already (using deadlock-detecting mutex is asking for
>>> error) -- as well as that no C++ implementer would use a more complex
>>> error-throwing deadlock-detecting mutex given a simpler alternative
>>> for static initialization.
>>>
>>> In particular, on UNIX, an implementer will use
>>> PTHREAD_MUTEX_INITIALIZER that initializes a non-ERRORCHECK mutex.
>>>
>>> On Windows, critical section is essentially a recursive
>>> deadlock-detecting (timed) mutex so it is relatively expensive and
>>> can fail.
>>>
>>> All it means that, on Windows, to implement static initialization, a
>>> C++ implementor has to use other primitives, most conveniently --
>>> InitOnceExecuteOnce -- that cannot fail unless the callback it
>>> executes fails.
>>>
>>>>
>>>>> "delayed" or "deferred" initialization of synchronization
>>>>> primitives that can be used to initialize static C++ object is
>>>>> entirely your fantasy. It cannot be used for this purpose, period.
>>>>
>>>> The mutex' constructor doesn't throw, so there must be delayed
>>>> initialization.
>>> Wrong. a mutex can be created during static initialization entirely
>>> in user space (like POSIX mutex on linux is created)
>>>
>>>> But as we've seen recently pthread Mutexes also
>>>> allow delayed initialization
>>> "Allow" does not mean C++ static initialization implementer has to
>>> use it. On Linux, mutex_lock tries light-weight user-space
>>> initialization internally so no need to reinvent that wheel for
>>> implementers. But of course on Linux any reasonable implementer will
>>> use pthread_once (which also does not have any delayed
>>> iniitialization), rather than a mutex.
>>>
>>>>  of the slow path and Win32 always
>>>> does the same.
>>> Yes, on Win32 C++ static initialization does not have to use mutex
>>> either. INIT_ONCE can be initialized statically to
>>> INIT_ONCE_STATIC_INIT -- which is all one needs for static
>>> initialization (coincidentally, on Win32 specifically
>>> InitOnceInitialize does not fail either but this is irrelevant to the
>>> issue of static C++ initialization).
>>
>> Iirc, I think a windows critical section might raise an error if its
>> been waiting for 30 days or something, deadlocked.
> Exactly, that's what I meant, just cited in the other response. It is,
> by behavior, a timed recursive mutex but user does not control the time.

Well, in that sense, okay. I see what you are getting at. :^)

On 9/24/2023 9:59 AM, Pavel wrote:
> Chris M. Thomasson wrote:
>> On 9/23/2023 2:58 PM, Pavel wrote:
>>> Bonita Montero wrote:
>>>> Am 23.09.2023 um 04:50 schrieb Pavel:
>>>>
>>>>> for some mutex it may fail, for some not. C++ standard never says
>>>>> that std::mutex can fail. ...
>>>>
>>>> std::mutex::lock() can throw a system_error.
>>> Wrong. The standard says that lock can throw while discussing general
>>> requirements for all types of mutices (mutex, recursive_mutex,
>>> timed_mutex, recursive_timed_mutex, shared_mutex, and
>>> shared_timed_mutex). Then, when discussing specific mutices, the
>>> standard says that recursive_mutex, recursive_timed_mutex and any of
>>> the shared mutices can throw system_error). About std::mutex the
>>> standard says no such thing.
>>>
>>> The only mentioning of an error for std::mutex is in a non-normative
>>> note that explains: "If the
>>> implementation can detect the deadlock, a
>>> resource_deadlock_would_occur error condition might be observed". We
>>> knew that already (using deadlock-detecting mutex is asking for
>>> error) -- as well as that no C++ implementer would use a more complex
>>> error-throwing deadlock-detecting mutex given a simpler alternative
>>> for static initialization.
>>>
>>> In particular, on UNIX, an implementer will use
>>> PTHREAD_MUTEX_INITIALIZER that initializes a non-ERRORCHECK mutex.
>>>
>>> On Windows, critical section is essentially a recursive
>>> deadlock-detecting (timed) mutex so it is relatively expensive and
>>> can fail.
>> [...]
>>
>> I don't think there is a timed wait for a windows critical section. I
>> know it has a try, but I cannot remember a timed wait...
> It is not a timed wait controlled by the user. But it waits for some
> time (specified in the registry) and then fails -- that is its way to
> *try* to detect a deadlock. Says the doc on EnterCriticalSection:
>
> "
> This function can raise EXCEPTION_POSSIBLE_DEADLOCK, also known as
> STATUS_POSSIBLE_DEADLOCK, if a wait operation on the critical section
> times out. The timeout interval is specified by the following registry
> value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
> Manager\CriticalSectionTimeout. Do not handle a possible deadlock
> exception; instead, debug the application.
> "

Thanks for your clarification. No problem. :^)

On 9/24/2023 11:41 AM, Chris M. Thomasson wrote:
> On 9/24/2023 2:50 AM, Michael S wrote:
>> On Sunday, September 24, 2023 at 11:09:31 AM UTC+3, Bonita Montero wrote:
>>> Am 24.09.2023 um 05:05 schrieb Chris M. Thomasson:
>>>
>>>> Why do you think that static initialization must use a std::mutex
>>>> anyway? ...
>>>
>>> Call it std::mutex or whatever. It is mandated that contenders
>>> are sleeping - that's not possible without sth. else than a mutex.
>>
>> Few dozens posts above I demonstrated an implementation
>> for pre-Vista Windows where contenders are sleeping just fine and
>> waking just fine and initialization of different objects proceeds
>> simultaneously just fine.  And it does not use mutex for that.
>> It uses SleepEx() for wait and QueueUserApc() for wakeup.
>
> Why? APC's open up a big can of worms.

Oh shit. I am starting to remember some nightmare code I had to debug
many moon ago that used async cancellation in POSIX threads.

>
>
>> It uses one global mutex (in form of critical section) for a short
>> while for metadata updates, but that's done for simplicity and
>> practicality rather than out of necessity. I am pretty sure that
>> with enough effort I can device a variant that achieves the same
>> with CaS.
>
>

On 9/24/2023 5:51 AM, Bonita Montero wrote:
> Am 24.09.2023 um 14:47 schrieb Michael S:
>
>> I don't say that is what should be done.
>> For me, calling abort() with as intelligible as practical error
>> message is
>> what should be done on hosted implementation.
>
> I _sometimes_ call terminate() on synchronization errors also, f.e. when
> a threads responds back to a thread which issued a task to this thread
> to prevent starving the other thread. But with the issuing thread first
> I don't terminate(). It simply depends on the situation and with static
> initialization it's the same.
>

Oh my god.

On 9/24/2023 11:49 AM, Chris M. Thomasson wrote:
> On 9/24/2023 11:41 AM, Chris M. Thomasson wrote:
>> On 9/24/2023 2:50 AM, Michael S wrote:
>>> On Sunday, September 24, 2023 at 11:09:31 AM UTC+3, Bonita Montero
>>> wrote:
>>>> Am 24.09.2023 um 05:05 schrieb Chris M. Thomasson:
>>>>
>>>>> Why do you think that static initialization must use a std::mutex
>>>>> anyway? ...
>>>>
>>>> Call it std::mutex or whatever. It is mandated that contenders
>>>> are sleeping - that's not possible without sth. else than a mutex.
>>>
>>> Few dozens posts above I demonstrated an implementation
>>> for pre-Vista Windows where contenders are sleeping just fine and
>>> waking just fine and initialization of different objects proceeds
>>> simultaneously just fine.  And it does not use mutex for that.
>>> It uses SleepEx() for wait and QueueUserApc() for wakeup.
>>
>> Why? APC's open up a big can of worms.
>
> Oh shit. I am starting to remember some nightmare code I had to debug
> many moon ago that used async cancellation in POSIX threads.
>
>
>
>>
>>
>>> It uses one global mutex (in form of critical section) for a short
>>> while for metadata updates, but that's done for simplicity and
>>> practicality rather than out of necessity. I am pretty sure that
>>> with enough effort I can device a variant that achieves the same
>>> with CaS.
>>
>>
>

Now, I am recalling async safe sync objects that must be used in a
signal handler for some reason.

On 9/24/23 14:17, Richard Damon wrote:
> On 9/24/23 12:17 PM, James Kuyper wrote:
>> On 9/24/23 08:04, Richard Damon wrote:
>>
....
>>> Demanding that specification change because YOU don't see how to meet
>>> them is very much "unprofessional"
>> No, it is very professional to complain about specifications that can't
>> be met. What is unprofessional is incorrectly concluding that they
>> cannot be met (especially after having had it explained to you many times).
> Note the emphasis on the word YOU.
>
> The fact THEY don't see how to do it, even after it has been
> demonstrated that it CAN be done, is what is unprofessional.
>
The problem is that Bonita has not recognized those demonstrations as
valid and relevant. That might be because she's misunderstood the
situation (which would be my guess), it might be because she's right, it
might be because you all have explained things to her poorly. However,
unless and until she's been convinced that the specification can be met,
it's entirely appropriate for her to complain about the "fact" that it
can't.

On 9/24/2023 2:19 PM, James Kuyper wrote:
> On 9/24/23 14:17, Richard Damon wrote:
>> On 9/24/23 12:17 PM, James Kuyper wrote:
>>> On 9/24/23 08:04, Richard Damon wrote:
>>>
> ...
>>>> Demanding that specification change because YOU don't see how to meet
>>>> them is very much "unprofessional"
>>> No, it is very professional to complain about specifications that can't
>>> be met. What is unprofessional is incorrectly concluding that they
>>> cannot be met (especially after having had it explained to you many times).
>> Note the emphasis on the word YOU.
>>
>> The fact THEY don't see how to do it, even after it has been
>> demonstrated that it CAN be done, is what is unprofessional.
>>
> The problem is that Bonita has not recognized those demonstrations as
> valid and relevant. That might be because she's misunderstood the
> situation (which would be my guess), it might be because she's right, it
> might be because you all have explained things to her poorly. However,
> unless and until she's been convinced that the specification can be met,
> it's entirely appropriate for her to complain about the "fact" that it
> can't.

A mutex that has to jump through atomic hoops during a contended lock
with any "delayed" resource allocation from the kernel is a no go. Bad
design, no good at all.

On 9/24/23 5:19 PM, James Kuyper wrote:
> On 9/24/23 14:17, Richard Damon wrote:
>> On 9/24/23 12:17 PM, James Kuyper wrote:
>>> On 9/24/23 08:04, Richard Damon wrote:
>>>
> ...
>>>> Demanding that specification change because YOU don't see how to meet
>>>> them is very much "unprofessional"
>>> No, it is very professional to complain about specifications that can't
>>> be met. What is unprofessional is incorrectly concluding that they
>>> cannot be met (especially after having had it explained to you many times).
>> Note the emphasis on the word YOU.
>>
>> The fact THEY don't see how to do it, even after it has been
>> demonstrated that it CAN be done, is what is unprofessional.
>>
> The problem is that Bonita has not recognized those demonstrations as
> valid and relevant. That might be because she's misunderstood the
> situation (which would be my guess), it might be because she's right, it
> might be because you all have explained things to her poorly. However,
> unless and until she's been convinced that the specification can be met,
> it's entirely appropriate for her to complain about the "fact" that it
> can't.

Refusing to accept Truth just puts her in the same league as Peter
Olcott and Flat Earthers. Someone asserting that something that has been
demonstrated isn't true has the burden of proof to actually show their
claim.

We have implementations that fully claim to be compliant in this, and
zero cases even hinting that they are in this aspect.

Arguing about it is the same as arguing about Russel's Teapot.

Am 24.09.2023 um 19:10 schrieb Pavel:

> so? everyone has been telling you initialization of simple mutices
> does not fail. After few hundred posts, you decided to agree?

lock() and unlock() might throw system_error.

Am 24.09.2023 um 18:47 schrieb Pavel:
> Bonita Montero wrote:

> Name one platform for which it is not guaranteed and that targets a
> compliant C++11+ implementation.

Any platform since lock() and unlock() might throw system_error()
as documented.

On 9/24/23 19:00, Richard Damon wrote:
....
> Refusing to accept Truth just puts her in the same league as Peter
> Olcott and Flat Earthers.

It's a big league - there's few humans who have never been a member,
though Bonita has spent far more time in that league than most people.

All I'm saying is that you should complain about her failure to accept
the truth - don't complain about her complaints, which are a reasonable
consequence of her unreasonable refusal to accept the truth.

On 9/24/23 7:10 PM, Bonita Montero wrote:
> Am 24.09.2023 um 18:47 schrieb Pavel:
>> Bonita Montero wrote:
>
>> Name one platform for which it is not guaranteed and that targets a
>> compliant C++11+ implementation.
>
> Any platform since lock() and unlock() might throw system_error()
> as documented.
>

Try again.

Not for pthreads, as you can ALWAYS create a mutex statically with
PTHREAD_MUTEX_INITIALZER, which will not return an error, and

there is no error condition returnable by pthread_mutex_lock that is not
caused by programmer error on a mutex so created, so no grounds for the
mutex to throw "system_error".

Remember, your need to show not that some mutex might fail, but that it
is impossible to create a mutex that won't fail.

Then there is also the fact that it has been pointed out that you don't
actually need a full mutex per object, but that some major libraries use
a single global mutex to protect a user-land built synchronization
object, where the single global mutex is only held for a very limited
time at the beginning and ending of each object initialization.

Until you show the ACTUAL ERROR with that code, your "impossible" claim
has been disproved with an example implementation that proves you to be
a liar (or an idiot).

The fact that YOU can't think of how to do it does not make it
impossible, it just shows your mental ability is not up to the needed
ability.

On 9/24/23 8:13 AM, Bonita Montero wrote:
> Am 24.09.2023 um 14:04 schrieb Richard Damon:
>
>> In fact, using a mutex the way you are decribing, because it can
>> fail, in "unprofessional", and more importantly, non-conforming.
>
> Yielding is unacceptable and the only second solution that sleeps,
> as the standard mandates. I don't understand what would be the
> problem to have a system_error on a synchronization failure with
> static initialization.
>

I don't think you understand what "Yielding" actually does.

Why do you think static initialization should be allowed to fail?

Maybe it is "unacceptable" to you, but WHY?

And why is the results of yielding WORSE than the program needing to
ABORT and not run.

Slow (if it actually does make it slow) is better than not running at all.

On 9/24/2023 4:35 PM, James Kuyper wrote:
> On 9/24/23 19:00, Richard Damon wrote:
> ...
>> Refusing to accept Truth just puts her in the same league as Peter
>> Olcott and Flat Earthers.
>
> It's a big league - there's few humans who have never been a member,
> though Bonita has spent far more time in that league than most people.
>
> All I'm saying is that you should complain about her failure to accept
> the truth - don't complain about her complaints, which are a reasonable
> consequence of her unreasonable refusal to accept the truth.

Well, that is fair enough. Touche.

On 9/24/2023 4:06 PM, Bonita Montero wrote:
> Am 24.09.2023 um 19:10 schrieb Pavel:
>
>> so? everyone has been telling you initialization of simple mutices
>> does  not fail. After few hundred posts, you decided to agree?
>
> lock() and unlock() might throw system_error.
>
>

Well, then it kind seems like you are try to suggest that any 100%
compliant and working program that uses threads, is a ticking time bomb
that can explode at random times, willy nilly?

On 9/6/2023 11:15 AM, Bonita Montero wrote:
> With C++11 static local or global data is initialized thread-safe.
[...]

I am wondering why Bonita kind of reminds of a slow walked version of
the following song wrt learning state of the art threading and sync
techniques?

https://youtu.be/FE-hBbBBGBs

;^)

On 9/10/2023 2:58 PM, Pavel wrote:
> Chris M. Thomasson wrote:
[...]
>> 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++.

Indeed. Windows has the API's necessary to implement it.

[...]

On 9/24/2023 8:18 PM, Chris M. Thomasson wrote:
> On 9/6/2023 11:15 AM, Bonita Montero wrote:
>> With C++11 static local or global data is initialized thread-safe.
> [...]
>
> I am wondering why Bonita kind of reminds of a slow walked version of
> the following song wrt learning state of the art threading and sync
> techniques?
>
> https://youtu.be/FE-hBbBBGBs
>
> ;^)
>

Actually, sometimes I think Bonita might a clever troll, that actually
knows how to programs threads. Strange.

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.

Am 25.09.2023 um 03:18 schrieb Richard Damon:

> Why do you think static initialization should be allowed to fail?

For the same reasons mutex::lock() and ::unlock()
may throw system_error.

On 9/25/23 4:00 AM, 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.
>

So, you admit you lied when you said the problem you claimed applied to
ALL operating systems.

The reason the Standard allows Mutex lock to throw the error is because
in some cases you might get an error, normally in response to a
programmer error.

The Standard just doesn't allow the implementation to use a Mutex in
those error conditions for initialization syncronization.

Again, you are showing your ignorance by insisting that the Standard
give leniency to the implementation to allow it to do things wrong.

On 9/25/23 4:02 AM, Bonita Montero wrote:
> Am 25.09.2023 um 03:18 schrieb Richard Damon:
>
>> Why do you think static initialization should be allowed to fail?
>
> For the same reasons mutex::lock() and ::unlock()
> may throw system_error.
>

Except that mutex::lock can't throw system_error in the use case for
proper use in static initialization.

You argument is basically, the Standard needs to allow for BAD
implementation to exist.

The fact you don't understand how the "good" implementations work, just
shows your ignorance.

Am 25.09.2023 um 13:15 schrieb Richard Damon:

> So, you admit you lied when you said the problem you claimed applied to
> ALL operating systems.

I never said that.

> The reason the Standard allows Mutex lock to throw the error is
> because in some cases you might get an error, normally in response
> to a programmer error.

You don't know that.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 24.09.2023 um 19:10 schrieb Pavel:
>
>> so? everyone has been telling you initialization of simple mutices
>> does not fail. After few hundred posts, you decided to agree?
>
>lock() and unlock() might throw system_error.

lock() and unlock() cannot throw any error.