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? ...
>
> It is mandated that contenders are sleeping

Really? I never had read the Standard, but somehow have troubles
believing that.
Would expect that it's matter of quality of implementations rather than
of mandate.
Even more so - requirement to wake up timely if sleeping
indeed happened. It's expected from good implementation, but
I can't believe that it's mandated by Standard.

Am 24.09.2023 um 13:15 schrieb Richard Damon:

> So, you still think that the Standard should allow a very common
> operation to fail in ways that the program can not handle it when
> another method exists to do the operation exists that has no
> opportunity for failure.

The program could easily handle that by catching a system_error.
There's nothing different from that if the constructor itself
throws an error.

Am 24.09.2023 um 13:18 schrieb Michael S:

> Really? I never had read the Standard, but somehow have troubles
> believing that.

Someone here cited the standard with that. Everything different
like spinning (not applicable in userspace) would be unprofessional.

On Sunday, September 24, 2023 at 2:35:09 PM UTC+3, Bonita Montero wrote:
> Am 24.09.2023 um 13:18 schrieb Michael S:
>
> > Really? I never had read the Standard, but somehow have troubles
> > believing that.
> Someone here cited the standard with that. Everything different
> like spinning (not applicable in userspace) would be unprofessional.

Can I conclude that you also didn't read the Standard?

As to what is professional and what not, it's matter of opinion
and circumstances. After all, we are talking about rare situation
during use of obscure language feature. On Linux or post-XP Windows
it is easy to be both robust and performant. But if platform in question
does not provide obvious both robust and performant way of dealing with
it, then many people, including myself, would prefer robust solution
over performant one. I.e. we will take a solution in which late comers are
waiting on done flag ina loop with Sleep(1) over dynamic allocation
of kernel object that can theoretically fail.

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.

On 9/24/23 7:33 AM, Bonita Montero wrote:
> Am 24.09.2023 um 13:15 schrieb Richard Damon:
>
>> So, you still think that the Standard should allow a very common
>> operation to fail in ways that the program can not handle it when
>> another method exists to do the operation exists that has no
>> opportunity for failure.
>
> The program could easily handle that by catching a system_error.
> There's nothing different from that if the constructor itself
> throws an error.
>

But it shouldn't NEED to, since the operation can be done without the
possibility of error.

And, for non-local initialization, it CAN'T.

On 9/24/23 7:34 AM, Bonita Montero wrote:
> Am 24.09.2023 um 13:18 schrieb Michael S:
>
>> Really? I never had read the Standard, but somehow have troubles
>> believing that.
>
> Someone here cited the standard with that. Everything different
> like spinning (not applicable in userspace) would be unprofessional.
>

Nope, Try to find it.

You are just showing you don't understand what you are talking about.

In fact, using a mutex the way you are decribing, because it can fail,
in "unprofessional", and more importantly, non-conforming.

Demanding that specification change because YOU don't see how to meet
them is very much "unprofessional"

Am 24.09.2023 um 14:01 schrieb Richard Damon:

> But it shouldn't NEED to, since the operation can be done without the
> possibility of error.

That isn't guaranteed for any platform.

> And, for non-local initialization, it CAN'T.

Non-local initializations are done before main() or before the
shared object initialization returns and therefore they don't
need any synchronization.

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.

On Sunday, September 24, 2023 at 3:13:21 PM UTC+3, 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 am not an expert in C++ Standard advocacy, rather close to
opposite of, but I can guess. Throwing system_error will create
an illusion of possibility of useful recovery where in reality useful
recovery is impossible.

Am 24.09.2023 um 14:21 schrieb Michael S:

> I am not an expert in C++ Standard advocacy, rather close to
> opposite of, but I can guess. Throwing system_error will create
> an illusion of possibility of useful recovery where in reality
> useful recovery is impossible.

This depends on the code you write if this is acceptable. Sometimes
there's also not a useful recovery when a thread responding to another
thread fails to lock a mutex, thereby letting the other thread waiting
forever; nevertheless there's a system_error with that.

On Sunday, September 24, 2023 at 3:35:46 PM UTC+3, Bonita Montero wrote:
> Am 24.09.2023 um 14:21 schrieb Michael S:
>
> > I am not an expert in C++ Standard advocacy, rather close to
> > opposite of, but I can guess. Throwing system_error will create
> > an illusion of possibility of useful recovery where in reality
> > useful recovery is impossible.
> This depends on the code you write if this is acceptable. Sometimes
> there's also not a useful recovery when a thread responding to another
> thread fails to lock a mutex, thereby letting the other thread waiting
> forever; nevertheless there's a system_error with that.

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.

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.

On Friday, September 22, 2023 at 6:32:02 PM UTC-4, Richard Damon wrote:
> >
> The fact that you are too stupid

Perhaps Richard could reflect on the fact that with regard to manners and
civility, he's also as stupid as they come. Something to work on. The
heavyweights that used to post here never had that problem.

Best regards,
Daniel

On 9/24/23 08:04, Richard Damon wrote:
> On 9/24/23 7:34 AM, Bonita Montero wrote:
....
>> Someone here cited the standard with that. Everything different
>> like spinning (not applicable in userspace) would be unprofessional.
>>
>
> Nope, Try to find it.
>
>
> You are just showing you don't understand what you are talking about.
>
> In fact, using a mutex the way you are decribing, because it can fail,
> in "unprofessional", and more importantly, non-conforming.
>
> 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).

Bonita Montero wrote:
> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku:
>
>> A possible design is that each *thread* has a wait semaphore.
>
> You'd have to register the binary semaphore and register as a waiter in
> one atomic step. You could do that with a DCAS'd ring, but you coudn't
> atomically update the link pointers of the other nodes at the same
> time you update the roots link pointers. And you would have the deallo-
> cation poblem, i.e. the memory of your object may never be deallocated.
> Show me your implementation !
> It's ridiculous because mutex are a cheap resource.
Cheap as compared to what? How is a mutex "cheaper" than other
synchronization primitives? Also, what exactly mutex operation(s) is/are
cheap? Also, what exactly mutex type is cheap? On what platform? A
blanket statement is never entirely true or false, nothing can be
"ridiculous" because of it.

> And if such imple-
> mentation would be possible the standard shouldn't mandate it since
> not every platform has a DCAS.
>

Bonita Montero wrote:
> Am 24.09.2023 um 14:01 schrieb Richard Damon:
>
>> But it shouldn't NEED to, since the operation can be done without the
>> possibility of error.
>
> That isn't guaranteed for any platform.
Name one platform for which it is not guaranteed and that targets a
compliant C++11+ implementation.

>
>> And, for non-local initialization, it CAN'T.
>
> Non-local initializations are done before main() or before the
> shared object initialization returns and therefore they don't
> need any synchronization.

Bonita Montero wrote:
> Am 24.09.2023 um 13:18 schrieb Michael S:
>
>> Really? I never had read the Standard, but somehow have troubles
>> believing that.
>
> Someone here cited the standard with that. Everything different
> like spinning (not applicable in userspace) would be unprofessional.
>
Kernel-level sleeping and waking up is more or less moving an execution
context from runlist to a waiting list and back. Why should such an
operation be fail-able?

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

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.

On 2023-09-24, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku:
>
>> A possible design is that each *thread* has a wait semaphore.
>
> You'd have to register the binary semaphore and register as a waiter in
> one atomic step. You could do that with a DCAS'd ring, but you coudn't
> atomically update the link pointers of the other nodes at the same
> time you update the roots link pointers. And you would have the deallo-
> cation poblem, i.e. the memory of your object may never be deallocated.

Now you're just throwing together words you don't understand.

> Show me your implementation !

E.g. old LinuxThreads in glibc, circa 2000:

https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe

The low level __pthread_lock and __pthread_unlock functions maintain a
queue, using a single-word atomic CAS.

There are suspend() and resume() functions for the waiting;
they are elsewhere.

If you look in restart.h you can see that those operations are defined
in two different ways, both of which use signals (not a semaphore per
thread). A suspending thread waits for the arrival of a signal,
resume is done by sending a signal. That's kind of semaphore-like;
and POSIX real-time signals can even queue up, like a counting sem.

> It's ridiculous because mutex are a cheap resource. And if such imple-
> mentation would be possible the standard shouldn't mandate it since
> not every platform has a DCAS.

Things can be done in ways you havn't thought about.

Atomic operations aren't required to achieve mutual exclusion among
processors that share memory.

As someone continually insisting on having expertise in concurrency,
you must be familiar with the research work of Leslie Lamport?

For instance, the paper _A Fast Mutual Exclusion Algorithm_ [1985].

Abstract:

"A new solution to the mutual exclusion problem is presented that, in the
absence of contention, requires only seven memory accesses. It assumes
atomic reads and atomic writes to shared registers."

Snipeet from Introduction which gives a clue as to the motivation:

"Recently, there has arisen interest in building shared-memory
multiprocessor computers by connecting standard processors and
memories, with as little modification to the hardware as possible.
Because ordinary sequential processors and memories do not have atomic
test-and-set operations, it is worth investigating whether
shared-memory mutual exclusion algorithms are a practical alternative."

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

Bonita Montero wrote:
> Am 23.09.2023 um 23:58 schrieb Pavel:
>
>>> 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.
>
> constexpr mutex() noexcept;
>
> https://en.cppreference.com/w/cpp/thread/mutex/mutex
so? everyone has been telling you initialization of simple mutices does
not fail. After few hundred posts, you decided to agree?

>
>> Wrong. a mutex can be created during static initialization entirely
>> in user space (like POSIX mutex on linux is created)
>
> If the mutex' constructor is noexcept the kernel-part for the slow
> path has to be initialized delayed while locking.
You can rename your favorite part of locking "initialization" for your
internal use; but it is advisable to use standard terms if you write for
others.

Regardless of how it is called, no part of simple mutex lock has to be
fail-able.

>
> Rest unread.
yet another broken promise

On 9/24/2023 1:08 AM, Bonita Montero wrote:
> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku:
>
>> A possible design is that each *thread* has a wait semaphore.
>
> You'd have to register the binary semaphore and register as a waiter in
> one atomic step. You could do that with a DCAS'd ring, but you coudn't
> atomically update the link pointers of the other nodes at the same
> time you update the roots link pointers. And you would have the deallo-
> cation poblem, i.e. the memory of your object may never be deallocated.
> Show me your implementation !
> It's ridiculous because mutex are a cheap resource. And if such imple-
> mentation would be possible the standard shouldn't mandate it since
> not every platform has a DCAS.
>

Pardon my French, but that is a rather horrible idea, for several reasons...

On 9/24/2023 1:09 AM, 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.
>
>

You lost me here.

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.

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