On 9/21/2023 5:40 AM, Bonita Montero wrote:
> Am 21.09.2023 um 13:36 schrieb Richard Damon:
>
>> Why?
>
> Because the initialization might only take a microsecond or less
> and a yield is a full timeslice, on Linux and Windows usually one
> millisecond.

An adaptive backoff can be a mixture of the PAUSE instruction aka x86,
and yield wrt the OS.

On 9/21/2023 7:17 AM, Bonita Montero wrote:
> Am 21.09.2023 um 15:05 schrieb David Brown:
>
>> "Yield" won't take a timeslice unless there is something else of the
>> same priority, waiting to run on the same core. ...
>
> Ok, you're right, but the code would be still unacceptable under load.
>

Wait, are you talking about a _pure_ spin lock in user space here? For
some reason you seem to be struggling with adaptive backoffs, that can
choose to wait in the kernel for a "really slow path", so to speak. Keep
in mind that spinning is already a slow path by default. Now, there is a
way to organize a program where a yield can be replaced by a
"try_to_do_something_else()" function. Its been a while sense I
implemented one. Man, how time flies!

On 9/21/2023 8:03 AM, Bonita Montero wrote:
> Am 21.09.2023 um 16:48 schrieb Michael S:
>
>> If initialization is short then contention is very unlikely.
>
> Maybe, but no one would cose this solutions if mutexes are available.
> Yielding in this situation is crap.
>

You tell em Bonita. You should start protesting about this in front of
Microsoft head quarters in Redmond.

On 9/19/2023 1:50 AM, Bonita Montero wrote:
> Am 19.09.2023 um 07:14 schrieb Chris M. Thomasson:
>
>> I assume going to "sleep" means waiting in the kernel on a slow path.
>> Otherwise, humm... Are you talking about user logic that sleeps for a
>> second or two? Why should that matter at all? The impl shall arrange
>> things such that there is no deadlock. Let me guess Bonita, you think
>> that user logic that waits for infinity while its trying to initialize
>> itself should be handled in the std? Humm... Not sure about you.
>
> You often seem confused.
>

Really? Actually, my comments here are trying to help you. But, you like
to flush them down the toilet and call me an idiot. Well, shit happens.

On 9/21/2023 12:51 AM, Bonita Montero wrote:
> Am 21.09.2023 um 06:25 schrieb Chris M. Thomasson:
>> On 9/20/2023 8:46 PM, Bonita Montero wrote:
>
>>> Am 20.09.2023 um 21:36 schrieb Chris M. Thomasson:
>
>>> A recursive lock is impossible here since the object might have
>>> been partitially initialized and when coming back this partitial
>>> initialization would happen again.
>
>> A recursive would only provide a, so of, false sense of security wrt
>> the infinite recursion that is present in the user code.
>
> A recursive lock wouldn't make sense here since the object might have
> beein partitially created when it re-enters the mutex which guards the
> initialization.
>

Huh? I must be misunderstanding you here. A Recursive mutex means it
allows the same thread to acquire it more than once. It can be detected
rather easily.

On 9/21/2023 2:02 AM, Bonita Montero wrote:
> Am 21.09.2023 um 10:38 schrieb Michael S:
>
>> Actually, considering that contention is very rare in practice, ...
>
> The initialization might last an arbitrary time, so spinning
> is inacceptable.
>
>> So even use of Futex | Critical Section | SRW lock,  although it make
>> a lot of sense in practice,  is not necessary from theoretical P.O.V.
>
> Why should a SRW-lock make sense here ? If the object isn't initialized
> iz can't be read meanwhile. And a futex isn't a replacement for a mutex
> but just a faster slow path for a mutex.
>
>
>

A futex can be used to build a mutex, semaphore, a condition variable,
ect... A futex is a nice building block that works out pretty damn good.

Have a lock-free algorithm that you want to make block on certain
conditions, build a predicate and we can use it with a futex.

On 2023-09-21, David Brown <david.brown@hesbynett.no> wrote:
> But I think for that kind of system, your recommended solution - don't
> have function-local statics that need such initialisation
> synchronisation - is far and away the most common solution.

It could be as simple as putting the same variable outside of the
function, so that the global construction takes care of it.

I don't think that global construction/initialization in C++ is a very
good feature. You often need to maintain a strict order among
global initializations. The order of global constructions is basically
left to chance. It might follow the order in which the object files
were linked or whatever.

Only initializations that have absolutely no dependencies can be
confidently put into the global scope.

A possible reason why some programmers put complex static
initializations into a block scope is to delay that initialization,
since it will happen at a time when all the global ones have done.

In my experience, global initialization can sometimes grow complex and
need to be broken into phases: early initialization, late
initialization. Possibly more than two.

Block scope static initialization could be serving as an /ad hoc/
late initialization.

--

I wonder whether anyone has ever experimented with a way of controlling
the order of global C++ initializations by manipulating link order.

Say that in a given implementation we can rely on the fact that if
object files a.o b.o c.o are linked in that order, then their global
constructions are done in that order.

We could then deduce the dependencies among them (say, from
header file inclusions: if b.cc includes "a.h", but a.cc does not
include "b.h", we can infer that b depends on a). Then topologically
sort the .o files accordingly.

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

On 9/21/2023 4:19 AM, David Brown wrote:
> On 21/09/2023 11:59, Michael S wrote:
>> On Thursday, September 21, 2023 at 12:03:01 PM UTC+3, Bonita Montero
>> wrote:
>>> Am 21.09.2023 um 10:38 schrieb Michael S:
>>>
>>>> Actually, considering that contention is very rare in practice, ...
>>>
>>> The initialization might last an arbitrary time, so spinning
>>> is inacceptable.
>>
>> Why is it unacceptable? The impact of needless wake up of the waiting
>> thread
>> once per tick is negligible in terms of system performance and not too
>> horrible in terms power consumption. The impact of needless sleep till
>> the
>> next tick is also insignificant under assumption that initialization
>> took long time.
>>
>> I'd call it non-ideal when better solutions available, but perfectly
>> acceptable otherwise.
>>
>
> I don't know why Bonita dislikes spinning and sleeping, but I know why
> /I/ don't like it as a solution.  Sleeping does not affect thread
> priority in the way mutexes do.  That means if one low priority thread
> starts the initialisation and takes the lock, then gets pre-empted by a
> higher priority thread that tries to take the lock, your whole system
> can deadlock.  (The high priority thread may be sleeping, but there may
> be a mid-priority thread that can run and blocks the low-priority thread
> from running.)
>
> This is going to be a more likely failure situation if you have fewer
> (or only one) cores.  But the same compilers and toolchains are used for
> a wide variety of systems - you can't pick a solution that might fail on
> some systems.  And note that these kinds of failures never turn up in
> testing - they are rare, and only happen at the worst possible moment
> after deployment.
>
> This is particularly a risk for real-time systems and embedded systems,
> where you are more likely to have fewer cores (perhaps only one), or
> maybe some of your cores are dedicated to real-time tasks and
> unavailable for other threads.  You will also likely have high priority
> and real-time priority threads, which will block the low-priority
> threads.  And on such systems there might be very serious costs or
> safety risks involved in system hangs - you want to be sure that they
> are not possible, to the best of practical abilities, rather than
> designing in a solution that has a definite non-zero chance of failure.
>
> Using mutexes avoids this problem, because if a high priority thread is
> waiting on a mutex held by a low priority thread, the holder's priority
> gets boosted to that of the high priority thread until it releases the
> lock.
>
> Spinning should only be used when you have full control of the
> priorities of threads that may take the spin lock, and can be sure it is
> safe.
>
>

Sometimes adaptive mutexs are not the "right tool" for the job because
they can and will spin a couple of times, wrt their spin count.
Basically, use the right tool for your job at hand. Fair enough?

On 9/21/2023 6:03 AM, David Brown wrote:
> On 21/09/2023 14:01, Michael S wrote:
>> On Thursday, September 21, 2023 at 2:19:59 PM UTC+3, David Brown wrote:
>>> On 21/09/2023 11:59, Michael S wrote:
>>>> On Thursday, September 21, 2023 at 12:03:01 PM UTC+3, Bonita Montero
>>>> wrote:
>>>>> Am 21.09.2023 um 10:38 schrieb Michael S:
>>>>>
>>>>>> Actually, considering that contention is very rare in practice, ...
>>>>>
>>>>> The initialization might last an arbitrary time, so spinning
>>>>> is inacceptable.
>>>>
>>>> Why is it unacceptable? The impact of needless wake up of the
>>>> waiting thread
>>>> once per tick is negligible in terms of system performance and not too
>>>> horrible in terms power consumption. The impact of needless sleep
>>>> till the
>>>> next tick is also insignificant under assumption that initialization
>>>> took long time.
>>>>
>>>> I'd call it non-ideal when better solutions available, but perfectly
>>>> acceptable otherwise.
>>>>
>>> I don't know why Bonita dislikes spinning and sleeping, but I know why
>>> /I/ don't like it as a solution. Sleeping does not affect thread
>>> priority in the way mutexes do. That means if one low priority thread
>>> starts the initialisation and takes the lock, then gets pre-empted by a
>>> higher priority thread that tries to take the lock, your whole system
>>> can deadlock. (The high priority thread may be sleeping, but there may
>>> be a mid-priority thread that can run and blocks the low-priority thread
>>> from running.)
>>>
>>> This is going to be a more likely failure situation if you have fewer
>>> (or only one) cores. But the same compilers and toolchains are used for
>>> a wide variety of systems - you can't pick a solution that might fail on
>>> some systems. And note that these kinds of failures never turn up in
>>> testing - they are rare, and only happen at the worst possible moment
>>> after deployment.
>>>
>>> This is particularly a risk for real-time systems and embedded systems,
>>> where you are more likely to have fewer cores (perhaps only one), or
>>> maybe some of your cores are dedicated to real-time tasks and
>>> unavailable for other threads. You will also likely have high priority
>>> and real-time priority threads, which will block the low-priority
>>> threads. And on such systems there might be very serious costs or
>>> safety risks involved in system hangs - you want to be sure that they
>>> are not possible, to the best of practical abilities, rather than
>>> designing in a solution that has a definite non-zero chance of failure.
>>>
>>> Using mutexes avoids this problem, because if a high priority thread is
>>> waiting on a mutex held by a low priority thread, the holder's priority
>>> gets boosted to that of the high priority thread until it releases
>>> the lock.
>>>
>>> Spinning should only be used when you have full control of the
>>> priorities of threads that may take the spin lock, and can be sure it is
>>> safe.
>>
>> The problem you mention does not apply to general-purpose systems
>> like Windows, Linux, BSD-linage Unixes, Solaris e.t.c. They all have
>> built-in avoidance of deadlocks caused by priority-inversion. Most
>> commonly it's done by applying random priority boosts.
>
> As far as I know, such random priority boosts will not boost a
> non-realtime priority thread to real-time priority on Linux (and
> presumably not on other systems).  That would negate the whole concept
> of realtime priority threads.

Right, afaict, it seems to tend towards SCHED_OTHER. That is no good for
real time systems. Usually, pure wait-free algorithms are okay for real
time.

>
>>
>> Also I don't see how mutex semantics can possibly help. The common
>> problem scenario is that low-priority thread that is doing
>> initialization is
>> preempted when it *does not* hold the mutex. The mutex is held for
>> two very short durations of flags update. The preemption is far more
>> likely to happen during the middle phase - constructor itself.
>>
>> On real-time system with 1 or 2  processors you probably want
>> completely different design in which a mutex is held during all duration
>> of initialization, but you can't expect such solution to be included
>> in g++/clang++/MSVC compiler support libraries.
>>
>
> Yes, you would need the mutex to be held during critical stages of the
> initialisation.
>
> I can understand that this would be expensive compared to spinlocks that
> would work fine for "normal" systems (especially with the random boosts
> you described).  And I understand that toolchains have to be optimised
> for normal situations, not things that are extremely rare even in
> particular niche situations.
>
> But getting threading, locking and synchronisation details right is very
> difficult - most programmers don't get it right.  But you can't tell
> that you have a problem by testing the code, as failures typically
> require extreme bad luck in timing.  So it always worries me when I see
> something that is hidden, which most programmers will assume "just
> works, by some compiler magic", but which can be a problem in some
> circumstances.
>
> (As another example, gcc's "libatomic" uses spinlocks - if you use
> std::atomic types on a microcontroller in situations where atomics would
> be useful, they will hang your system any time there is a coincidental
> access.)
>
>> Which again brings us to the point made by myself  and few others:
>> don't do it! Don't use function-local static objects with constructors.
>> Or, at least don't use them in multitasking scenarios. Compiler's one
>> time initialization infrastructure can be super-robust, but being generic
>> it's unlikely to be optimal answer in any concrete scenario.
>>
>
> Yes, that is one option.  You can also use "constinit" statics safely.
> And gcc has a "-fno-threadsafe-statics" option (also useable as a
> pragma, but unfortunately not as a neater __attribute__) that puts the
> responsibility of ensuring things are threadsafe onto the user.
>
>
>

On 2023-09-21, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 9/21/2023 5:40 AM, Bonita Montero wrote:
>> Am 21.09.2023 um 13:36 schrieb Richard Damon:
>>
>>> Why?
>>
>> Because the initialization might only take a microsecond or less
>> and a yield is a full timeslice, on Linux and Windows usually one
>> millisecond.
>
> An adaptive backoff can be a mixture of the PAUSE instruction aka x86,
> and yield wrt the OS.

Ideally there shouldn't be a difference? In user mode execution, PAUSE
should be a privileged instruction. User space must not pause the
machine until an interrupt occurs. The privileged instruction will trap
to the kernel, where it becomes equivalent to a yield().

In the kernel, the lowest-priority idle task might execute that
instruction in a loop: the real one, not the trap.

When the scheduler determines there is truly nothing to do then it is
legitimate to dispatch an idle task which suspends the processor until
an external event.

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

On 9/21/2023 5:37 AM, Bonita Montero wrote:
> Am 21.09.2023 um 13:19 schrieb David Brown:
>
>> I don't know why Bonita dislikes spinning and sleeping, ...
>
> I only dislike spinning in userspace except when there's a
> limit to go for the slow path.

That's fine. For some reason I like to think of a spin is a slow path,
and a wait in the kernel is a "really" slow path! Fair enough? ;^)

> The thread holding a spinlock
> can be scheduled away an arbitrary time, that's unacceptable.

On 9/21/2023 7:56 AM, Scott Lurndal wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 21.09.2023 um 10:38 schrieb Michael S:
>>
>>> Actually, considering that contention is very rare in practice, ...
>>
>> The initialization might last an arbitrary time, so spinning
>> is inacceptable.
>
> It's rare in practice because good programmers very seldom[*] use
> non-global static variables in threaded applications.
>
> [*] Effectively never.
>

Well, I concur with this. :^)

On Thursday, September 21, 2023 at 9:10:36 PM UTC+3, David Brown wrote:
>
> Looking at generated code (using godbolt.org) for Linux, it seems there
> is just a single byte boolean guard per object - there is no thread id
> or anything else stored per object. I don't know what is going on
> inside "__cxa_guard_acquire" and other such functions, however.

That's not what I see on x86-64.
I see size of guard object = 8 bytes. Both Windows and Linux, both
gcc and clang.

On 9/20/23 11:46 PM, Bonita Montero wrote:
> Am 20.09.2023 um 21:36 schrieb Chris M. Thomasson:
>
>> A recursive lock would be interesting here...
>
> A recursive lock is impossible here since the object might have
> been partitially initialized and when coming back this partitial
> initialization would happen again.
>

If you get into a recursion of the SAME variable initialization, you
have a fundamental issue with your program design.

If to initialize variable A, you first have to have initialized that
same variable A, you have blocked yourself. Hanging in a Deadlock, or
aborting with a stack trace are reasonable responses. Since by the
defined behavior, the program has an essential deadlock, you can't
expect the system to find some magic to proceed around the problem. (I
don't think this triggers any Undefined Behavior to allow magic).

Bonita Montero wrote:

> This doesn't matter,
If this does not matter, why to mention it?

> because it's clear that static initialization
> can't work any other way than with a mutex. Yielding is inacceptable
> and spinlocking is inacceptable for reasons I've describet multiple
> times.
>
>> This is irrelevant to the discussion, but still is wrong:
>
> There's a non-initialized BSS segment with every executable and every
> shared library. This isn't physically part of the executable file but
> there's only a declared size to reserve. This block is initially com-
> pletely zero. This helps the C++ implementation since every static
> local object has initially an initialized-flag which is zero. This
> is stored along with the object itself.
How does the above prove your wrong point that initialization of static
synchronization primitives always may fail? It actually disproves this.
Whether using BSS or DATA segment (which depends on the requested
initial values), if the program is loaded successfully,
constant-initialized static variables are initialized without failure.

Bonita Montero wrote:
> Am 21.09.2023 um 09:58 schrieb Bonita Montero:
>
>>> They are only set to zero if they are not initialized explicitly.
>
>> I'm not talking about what the standad says but how it's implemented
>> with all operating systems that support virtual memory.
>
> This shows "all zero" on all modern operating systems:
>
> #include <iostream>
> #include <algorithm>
>
> using namespace std;
>
> int main()
> {
>     static char mem[0x1000000];
>     bool zero = find_if( mem, end( mem ), []( char c ) -> bool {
> return c; } ) == end( mem );
>     cout << (zero ? "all zero" : "has non-zero") << endl;
> }
What are you trying to prove? Your attempts on distraction are not
fooling anyone.

static pthread_once_t po = PTHERAD_ONCE_INIT;
will also be all zero. No possibility of runtime failure. No need to
change the standard.

Am 21.09.2023 um 20:19 schrieb Chris M. Thomasson:

> On 9/21/2023 12:47 AM, Bonita Montero wrote:

>> We discussed yield with periodic polling.

> An adaptive backoff ...
Do you have ADHD ?
We discussed yield with periodic polling.

Am 21.09.2023 um 20:25 schrieb Chris M. Thomasson:
> On 9/21/2023 7:17 AM, Bonita Montero wrote:
>> Am 21.09.2023 um 15:05 schrieb David Brown:
>>
>>> "Yield" won't take a timeslice unless there is something else of the
>>> same priority, waiting to run on the same core. ...
>>
>> Ok, you're right, but the code would be still unacceptable under load.
>>
>
> Wait, are you talking about a _pure_ spin lock in user space here?
> For some reason you seem to be struggling with adaptive backoffs, ...

No, we were discussing yielding.

Am 21.09.2023 um 20:21 schrieb Chris M. Thomasson:
> On 9/21/2023 5:40 AM, Bonita Montero wrote:
>> Am 21.09.2023 um 13:36 schrieb Richard Damon:
>>
>>> Why?
>>
>> Because the initialization might only take a microsecond or less
>> and a yield is a full timeslice, on Linux and Windows usually one
>> millisecond.
>
> An adaptive backoff can be a mixture of the PAUSE instruction aka x86,
> and yield wrt the OS.

Do you have a mental disorder ?
We were discussing yielding.

Am 21.09.2023 um 20:38 schrieb Chris M. Thomasson:
> On 9/21/2023 2:02 AM, Bonita Montero wrote:
>> Am 21.09.2023 um 10:38 schrieb Michael S:
>>
>>> Actually, considering that contention is very rare in practice, ...
>>
>> The initialization might last an arbitrary time, so spinning
>> is inacceptable.
>>
>>> So even use of Futex | Critical Section | SRW lock,  although it make
>>> a lot of sense in practice,  is not necessary from theoretical P.O.V.
>>
>> Why should a SRW-lock make sense here ? If the object isn't initialized
>> iz can't be read meanwhile. And a futex isn't a replacement for a mutex
>> but just a faster slow path for a mutex.
>>
>>
>>
>
> A futex can be used to build a mutex, semaphore, a condition variable,
> ect... A futex is a nice building block that works out pretty damn good.

We were disussing SRW-locks, how they're implemented doesn't matter here.

> Have a lock-free algorithm that you want to make block on certain
> conditions, build a predicate and we can use it with a futex.

Am 22.09.2023 um 04:21 schrieb Pavel:

> How does the above prove your wrong point that initialization of static
> synchronization primitives always may fail? ...

The mutex is created along with the static object from zeroed memory
whene there's contention. At least this may fail. And with Windows
the synchronization may also fail.

Am 21.09.2023 um 20:34 schrieb Chris M. Thomasson:
> On 9/21/2023 12:51 AM, Bonita Montero wrote:
>> Am 21.09.2023 um 06:25 schrieb Chris M. Thomasson:
>>> On 9/20/2023 8:46 PM, Bonita Montero wrote:
>>
>>>> Am 20.09.2023 um 21:36 schrieb Chris M. Thomasson:
>>
>>>> A recursive lock is impossible here since the object might have
>>>> been partitially initialized and when coming back this partitial
>>>> initialization would happen again.
>>
>>> A recursive would only provide a, so of, false sense of security wrt
>>> the infinite recursion that is present in the user code.
>>
>> A recursive lock wouldn't make sense here since the object might have
>> beein partitially created when it re-enters the mutex which guards the
>> initialization.
>>
>
> Huh? I must be misunderstanding you here. A Recursive mutex means it
> allows the same thread to acquire it more than once. It can be detected
> rather easily.

It's not about how recursion may be detected here but that any kind
of recursion doesn't make sense here.

Am 22.09.2023 um 03:18 schrieb Richard Damon:

> If you get into a recursion of the SAME variable initialization, you
> have a fundamental issue with your program design.

That's what I said.

Bonita Montero wrote:
> Am 17.09.2023 um 21:47 schrieb Richard Damon:
>
>> Why does it need to take into account that an BAD implementation might
>> fail.
>
> With the deferred initialization of a C++ mutex the mutex
> could fail on synchronization even without being bad.
A "deferred" initialization of a static sync primitive used to sync
static initialization of a C++ object is not only unnecessary (constant
initialization is enough) but also would be useless if used. Because how
would you correctly synchronize this "deferred" initialization itself if
the initialization of the static object is requested concurrently from 2
threads. You should stop invent and talk nonsense.

Bonita Montero wrote:
> Am 21.09.2023 um 02:42 schrieb Pavel:
>
>> Then there are lots of these on prevalent platforms that either cannot
>> fail ...
>
> The standard shoudln't mandate such platform capabilities.
It **is** the job of the standard authors to assume what elementary
operations can and what cannot fail and build their specs upon that.
They may do it more or less successfully. In this case, *at least* the
modern prevalent platforms (whereas modern means those that were alive
by the time C++ 11 was adopted or appeared soon after) have the
syncroniztion primitives that can be created and locked without a
failure. In fact, you failed to point out a single platform where such
capabilities are absent. Hence the standard authors did a very good job
in this particular regard and there is nothing to change in this regard.
Plain and simple.