On 9/21/23 10:28 PM, Bonita Montero wrote:
> 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.
>

Who said anything about "periodic" polling.

"Adaptive Backoff" is spin loop waiting for a short period of time
(length of time based on factors previously measured) after which it
decides to yield, and when that comes back, we try polling again.

Maybe you don't actually understand how any of this stuff works, because
people aren't using the "buzzwords" in the exact formula you think of them.

Am 22.09.2023 um 05:14 schrieb Richard Damon:

> Who said anything about "periodic" polling.

When you yield you have to do periodic polling since each yield-wakeup
doesn't guarante that you get the lock.

> "Adaptive Backoff" ...

I know what adaptive backoff is, but we weren't in this context
at this point.

Am 22.09.2023 um 04:25 schrieb Pavel:

> What are you trying to prove? ..

THat mem is initiallly zero, although this isn't guarenteed for
static fundamental types.

Am 22.09.2023 um 04:50 schrieb Pavel:

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

A lock may be never contended or contended very lately, so that
delayed allocation of the kernel semaphore may make sense.

Am 22.09.2023 um 04:58 schrieb Pavel:

> It **is** the job of the standard authors to assume what elementary
> operations can and what cannot fail and build their specs upon that.

Mutex synchronization can fail at least in C++ because of delayed
initialization since the constructor itself of mutex is noexcept.
It's the same with whatever is used for static initializatiionsince
the mutex-ish data structure is created when there's contention.

On 2023-09-22, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 22.09.2023 um 04:50 schrieb Pavel:
>
>> 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.
>
> A lock may be never contended or contended very lately, so that
> delayed allocation of the kernel semaphore may make sense.

Do you realize that if multiple threads race, they must somehow create a
single semaphore? One thread must create that semaphore and the others
use it?

And do you not see that that is itself an instance of the once-only
initialization problem? We have a semaphore handle, which must be
initialized once with a single semaphore object, which is used by
every thread that comes later?

If you've solved that problem, then can you explain why you wouldn't
get rid of the semaphore and just apply the solution directly to the
object you're actually trying to initialize?

--
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 2023-09-22, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 22.09.2023 um 04:58 schrieb Pavel:
>
>> It **is** the job of the standard authors to assume what elementary
>> operations can and what cannot fail and build their specs upon that.
>
> Mutex synchronization can fail at least in C++ because of delayed
> initialization since the constructor itself of mutex is noexcept.

Based on what hypothesis? That objects with noexcept constructors
necessarily keep an exception bottled up inside, which goes off at some
later inopportune moment?

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

Am 22.09.2023 um 07:15 schrieb Kaz Kylheku:

> Do you realize that if multiple threads race, they must somehow create a
> single semaphore? One thread must create that semaphore and the others
> use it?

C++ enforces delayed creation by having a noexcept mutex constructor.
The only way to have delayed initialization with that is to specula-
tively create the semaphore on contention and and try to permanently
assign it to the mutex with a CAS. If the cas fails because another
contender has allocated the semaphore the semaphore is discarded,
i.e. given back to the kernel, and the semaphore already allocated
by another contender is used.
There's no way to handle that differently while a C++ mutex' is noecept.

Am 22.09.2023 um 07:34 schrieb Kaz Kylheku:

> On 2023-09-22, Bonita Montero <Bonita.Montero@gmail.com> wrote:

>> Mutex synchronization can fail at least in C++ because of delayed
>> initialization since the constructor itself of mutex is noexcept.

> Based on what hypothesis? That objects with noexcept constructors
> necessarily keep an exception bottled up inside, which goes off at
> some later inopportune moment?

As the mutex constructor is noexcept you can't allocate a kernel
semaphore within that because the allocation can fail. So the
allocation has to happen inside lock(), optimally at the first
time there's contention, since lock() allows to throw a system_error.

On Friday, September 22, 2023 at 8:16:11 AM UTC+3, Kaz Kylheku wrote:
> On 2023-09-22, Bonita Montero <Bonita....@gmail.com> wrote:
> > Am 22.09.2023 um 04:50 schrieb Pavel:
> >
> >> 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.
> >
> > A lock may be never contended or contended very lately, so that
> > delayed allocation of the kernel semaphore may make sense.
> Do you realize that if multiple threads race, they must somehow create a
> single semaphore? One thread must create that semaphore and the others
> use it?
>
> And do you not see that that is itself an instance of the once-only
> initialization problem? We have a semaphore handle, which must be
> initialized once with a single semaphore object, which is used by
> every thread that comes later?
>
> If you've solved that problem, then can you explain why you wouldn't
> get rid of the semaphore and just apply the solution directly to the
> object you're actually trying to initialize?
> --

That's not the same.
The nature of initialization of local static object is unknown to C++
runtime support library. It can be short or long, compute intensive
or I/O intensive or even wait-intensive. The variability is what makes
the job challenging.
On the other hand, creation of kernel semaphore has well-known
characteristics - it is relatively short and compute-intensive.
With such characteristics, one does not need to invent complicated
schemes. A simplest solution will be adequate.
I.e. in the early stages of initialization you create a master mutex
with fully-initialized kernel mutex. Later on you use this master
mutex to serialize deferred part of initialization of other mutexes
and semaphores.

Pay attention, I didn't say that it's how it works in popular implementations.
Just say that it is possible and even somewhat sensible.

> TXR Programming Language: http://nongnu.org/txr
> Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
> Mastodon: @Kazi...@mstdn.ca
> NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 21/09/2023 20:39, Kaz Kylheku wrote:
> 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.
>

Yes, that is often the case. But there can be complications if this
requires dynamic code. There is the well-known matter of initialisation
/ construction order for statically allocated objects in C++. In
embedded systems, there is another matter - the system may not be ready
to handle the object's initialisation code until some of main()'s code
has run (such as for setting up hardware like external memory, clocks,
etc.).

The typical practice is to put the static objects outside of any
functions, and to use initialisation methods (or stand-alone functions)
rather than constructors. This works well enough, but you lose the
strong guarantees of object consistency that you get with constructors
(unless you have a "initialised" flag in each object, and check it for
each method - a not insignificant overhead).

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

You can improve things with compiler extensions, such as gcc's
"init_priority" attribute. Perhaps that could be standardised in some
way. Together with inline variables, this would, I think, eliminate
most cases of "singleton" patterns or the need to use lazy or delayed
construction to enforce particular orderings.

To be honest, I have difficulty thinking of many situations where you
would need a statically allocated object that is not constructed until
first use, let alone needing thread-safe construction. I think it would
have been better if C++ had effectively hoisted static locals to
file-scope level for constructor/destructor purposes, while retaining
scope and access restrictions - just like in C. Let those few
situations where you actually need initialisation control use an "init"
method, with whatever locking or synchronisation you deem appropriate.

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

Using link order for that sounds extremely fragile. You can rely on the
order of definitions within a single translation unit (though inline
variables may make a mess of that if you are inconsistent). And if you
use compiler extensions (like gcc's "init_priority" attribute), you can
rely on them. But using link order sounds risky to me unless you have
specific toolchain-documented ways to handle this.

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

If you are working with a manual linker file, and a specific toolchain
with a specific version, you can certainly do that kind of thing. In my
embedded (not embedded Linux) projects, the toolchain is always fixed at
a particular version (almost always a gcc toolchain), and I have the
linker file for it. I can see how the global constructors are called,
and make sure they are linked and run in exactly the order I want. But
in other types of programming, you don't have that kind of control -
only a tiny fraction of C++ programmers are even aware of "linker files"
or how you could control linking, and most don't have that kind of
control of the toolchains used for their code even if they know how to
do it.

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

This all needs a "whole program" overview, which would be a huge step
for C++.

On 21/09/2023 23:44, Michael S wrote:
> 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.
>

<https://godbolt.org/z/WTax3T13s>

It is entirely possible that the guard gets more space, for alignment
purposes. But it is easy to see from the generated assembly here that
only a single byte is read and tested for the guard. When compiling
with 32-bit ARM gcc, a 32-bit word is read, but it is left-shifted by 31
bits before testing. That means all but the LSB is ignored.

The storage to the guard object (when "-fno-threadsafe-statics" is not
in operation) is done by the "__cxa_guard_release" function, so I don't
know what that actually stores - all you can see from the assembly here
is what is read.

On 9/22/23 12:40 AM, Bonita Montero wrote:
> Am 22.09.2023 um 04:25 schrieb Pavel:
>
>> What are you trying to prove? ..
>
> THat mem is initiallly zero, although this isn't guarenteed for
> static fundamental types.
>

Except that it is.

It isn't guaranteed for "auto" variables, but is for static variables,
those are ALWAYS zero-initialized at the start of program.

Maybe you should actually read the Standard.

On 9/22/23 12:39 AM, Bonita Montero wrote:
> Am 22.09.2023 um 05:14 schrieb Richard Damon:
>
>> Who said anything about "periodic" polling.
>
> When you yield you have to do periodic polling since each yield-wakeup
> doesn't guarante that you get the lock.
>
>> "Adaptive Backoff" ...
>
> I know what adaptive backoff is, but we weren't in this context
> at this point.
>
>

Maybe YOU aren't, but "Adaptive Backoff" is one way to implement what I
was talking about.

Just shows that you don't actually know what we are talking about.

On Friday, September 22, 2023 at 2:06:05 PM UTC+3, David Brown wrote:
> On 21/09/2023 23:44, Michael S wrote:
> > 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.
> >
> <https://godbolt.org/z/WTax3T13s>
>
> It is entirely possible that the guard gets more space, for alignment
> purposes.

It's not "possible", it's fact. You can see it on godbolt with right setting
of presentation flags.
.comm _ZGVZ3foovE1a,8,8
https://godbolt.org/z/bhx3dar17
I don't believe that it has anything to do with alignment. Byte variables
do not need alignment, even for atomicity.

> But it is easy to see from the generated assembly here that
> only a single byte is read and tested for the guard.

It's easy to see that compiled code uses only first byte.
It's not easy to see how the storage used by __cxa_guard_xxx
support routines.

> When compiling
> with 32-bit ARM gcc, a 32-bit word is read, but it is left-shifted by 31
> bits before testing. That means all but the LSB is ignored.
>

On 32-bit ARM the size=4
On 64-bit ARM the size=8
On 32-bit x86 the size=8

> The storage to the guard object (when "-fno-threadsafe-statics" is not
> in operation) is done by the "__cxa_guard_release" function, so I don't
> know what that actually stores - all you can see from the assembly here
> is what is read.

On Friday, September 22, 2023 at 2:30:22 PM UTC+3, Richard Damon wrote:
> On 9/22/23 12:40 AM, Bonita Montero wrote:
> > Am 22.09.2023 um 04:25 schrieb Pavel:
> >
> >> What are you trying to prove? ..
> >
> > THat mem is initiallly zero, although this isn't guarenteed for
> > static fundamental types.
> >
> Except that it is.
>
> It isn't guaranteed for "auto" variables, but is for static variables,
> those are ALWAYS zero-initialized at the start of program.
>
> Maybe you should actually read the Standard.

TI tools for C5000 family were known to ignore this part of the Standard.
At least for C. I newer used TI C++ compilers.
In early 2000s they had a special flag that forced a standard
behavior. I am not sure that such flag existed in 90s and for earlier
families, esp. for C20/C25.

Am 22.09.2023 um 13:31 schrieb Richard Damon:

> Just shows that you don't actually know what we are talking about.

We're talking about if everything different like a mutex is acceptable
here. And it isn't. Yielding might have a too high delay under load
and spinning is dangerous in userspace because of what I've said.

On 22/09/2023 13:58, Michael S wrote:
> On Friday, September 22, 2023 at 2:30:22 PM UTC+3, Richard Damon wrote:
>> On 9/22/23 12:40 AM, Bonita Montero wrote:
>>> Am 22.09.2023 um 04:25 schrieb Pavel:
>>>
>>>> What are you trying to prove? ..
>>>
>>> THat mem is initiallly zero, although this isn't guarenteed for
>>> static fundamental types.
>>>
>> Except that it is.
>>
>> It isn't guaranteed for "auto" variables, but is for static variables,
>> those are ALWAYS zero-initialized at the start of program.
>>
>> Maybe you should actually read the Standard.
>
> TI tools for C5000 family were known to ignore this part of the Standard.
> At least for C. I newer used TI C++ compilers.
> In early 2000s they had a special flag that forced a standard
> behavior. I am not sure that such flag existed in 90s and for earlier
> families, esp. for C20/C25.
>

There's a reason TI's tools were known as "Code Composter", rather than
"Code Composer" as it said on the box...

I don't know of any other tools (C or C++) than TI's that did not zero
out uninitialised data at startup, but TI's were famous for it. It
caused a lot of "fun" for developers who could not figure out why their
code sometimes worked and sometimes failed (depending on the old
contents of the ram), and a lot of unnecessarily inefficient portable
code that explicitly initialised static data with zeros in case someone
used TI's tools.

On 22/09/2023 13:50, Michael S wrote:
> On Friday, September 22, 2023 at 2:06:05 PM UTC+3, David Brown wrote:
>> On 21/09/2023 23:44, Michael S wrote:
>>> 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.
>>>
>> <https://godbolt.org/z/WTax3T13s>
>>
>> It is entirely possible that the guard gets more space, for alignment
>> purposes.
>
> It's not "possible", it's fact. You can see it on godbolt with right setting
> of presentation flags.
> .comm _ZGVZ3foovE1a,8,8
> https://godbolt.org/z/bhx3dar17
> I don't believe that it has anything to do with alignment. Byte variables
> do not need alignment, even for atomicity.
>
>> But it is easy to see from the generated assembly here that
>> only a single byte is read and tested for the guard.
>
> It's easy to see that compiled code uses only first byte.
> It's not easy to see how the storage used by __cxa_guard_xxx
> support routines.

Perhaps the larger guard variable size is used between the
__cxa_guard_acquire, and the cxa_guard_release calls? In the end, I am
quite confident that the guard variable gets a 1 written to it, but it
could get some kind of thread information written during the actual
construction.

>
>> When compiling
>> with 32-bit ARM gcc, a 32-bit word is read, but it is left-shifted by 31
>> bits before testing. That means all but the LSB is ignored.
>>
>
> On 32-bit ARM the size=4
> On 64-bit ARM the size=8
> On 32-bit x86 the size=8
>
>> The storage to the guard object (when "-fno-threadsafe-statics" is not
>> in operation) is done by the "__cxa_guard_release" function, so I don't
>> know what that actually stores - all you can see from the assembly here
>> is what is read.

On 9/21/2023 11:52 PM, Bonita Montero wrote:
> Am 22.09.2023 um 07:15 schrieb Kaz Kylheku:
>
>> Do you realize that if multiple threads race, they must somehow create a
>> single semaphore? One thread must create that semaphore and the others
>> use it?
>
> C++ enforces delayed creation by having a noexcept mutex constructor.
> The only way to have delayed initialization with that is to specula-
> tively create the semaphore on contention and and try to permanently
> assign it to the mutex with a CAS. If the cas fails because another
> contender has allocated the semaphore the semaphore is discarded,
> i.e. given back to the kernel, and the semaphore already allocated
> by another contender is used.

Fwiw, that's exactly how this works, I posted about it elsewhere in this
thread:
______________________
static foo* g_foo = nullptr;

foo* l_foo = g_foo; // atomic load

if (! l_foo)
{ foo* t_foo = new foo;
foo* cmp = nullptr;

// CAS would update the comparand on failure.
// Take special note of that...

// mb release

if (! CAS(&g_foo, &cmp, t_foo)) // atomic rmw
{
// failed!!! well, shit happens!
delete t_foo;
t_foo = cmp;
// mb acquire
}

// I forgot to do this in my prior pseudo code.
// ARGH!!! ;^o

l_foo = t_foo; // damn it, sorry again.
}

else
{ // mb acquire
}

l_foo->bar();
______________________

> There's no way to handle that differently while a C++ mutex' is noecept.

Why do you say that!? A futex does not make the user code create any
kernel resources. You are a fairly stubborn person! :^)

Am 22.09.2023 um 19:30 schrieb Chris M. Thomasson:

> Why do you say that!? A futex does not make the user code create any
> kernel resources. You are a fairly stubborn person! :^)

A futex is a replacement for the slow path, replacing a binary
semaphore. It requires to make the futexes's address to be read
-only to trap accesses and it requires a waiter's queue inside
the kernel.
Your misconception is that you think the futex is pure userspace,
but the difference is just that there's no explicit kernel-call
but a MMU-trap, which is faster on most CPUs than a explicit
kernel-call. So a futex is not possible without a MMU, documented
here: https://bugzilla.kernel.org/show_bug.cgi?id=78881

On 9/21/2023 7:30 PM, Bonita Montero wrote:
> 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 faster slow path? A slow path using a futex or a semaphore are "slow"
by default. They go into the kernel. Afaict, you have very limited
experience with them. Fwiw, here is a pretty nice rwmutex that has no
loops in its logic:

https://vorbrodt.blog/2019/02/14/read-write-mutex

I created this many moons ago. It was fun to design. No loops can be a
pretty tall order! ;^)

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

Huh? Were are discussing static initialization and how a futex can be
used to handle it. Take note of the name of the thread itself. A rwmutex
can be implemented with a futex for the slow paths, no problem.

>> 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 9/21/2023 7:31 PM, Bonita Montero wrote:
> 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.
>
>

Sometimes you make blood want to shoot out of my eyes when I read what
you wrote.

On 9/22/2023 4:30 AM, Richard Damon wrote:
> On 9/22/23 12:40 AM, Bonita Montero wrote:
>> Am 22.09.2023 um 04:25 schrieb Pavel:
>>
>>> What are you trying to prove? ..
>>
>> THat mem is initiallly zero, although this isn't guarenteed for
>> static fundamental types.
>>
>
> Except that it is.
>
> It isn't guaranteed for "auto" variables, but is for static variables,
> those are ALWAYS zero-initialized at the start of program.
>
> Maybe you should actually read the Standard.

Afaict, Bonita needs to study up on a great many things when it comes to
synchronization. Sometimes, I think Bonita is actually trolling on
purpose... Humm...

Am 22.09.2023 um 19:41 schrieb Chris M. Thomasson:

> Afaict, Bonita needs to study up on a great many things when it comes
> to synchronization. Sometimes, I think Bonita is actually trolling on
> purpose... Humm...

The problem is not that I don't understand synchronization, the problem
is that I don't accept your objections where they don't fit the context.