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.

On 9/19/2023 1:46 AM, Bonita Montero wrote:
> Am 19.09.2023 um 07:01 schrieb Chris M. Thomasson:
>
>>> I've shown that static initialization actually uses a mutex per object.
>
>> Really?
>
> Here, a third time the code for you:
[snip code]

That does mean every impl must use a mutex per object wrt static
initialization. Just because you claim that they do, does not make it so.

Am 19.09.2023 um 11:08 schrieb Chris M. Thomasson:

> That does mean every impl must use a mutex per object wrt static
> initialization. Just because you claim that they do, does not make
> it so.

I've run the code with MSVC, libstdc++ and libc++, and with all
implementations the code runs about a second, so there's no central
mutex for all static initializations, but a mutex per static object.
I've told that multiple times and you didn't understand that.

On 9/19/23 5:36 AM, Bonita Montero wrote:
> Am 19.09.2023 um 11:08 schrieb Chris M. Thomasson:
>
>> That does mean every impl must use a mutex per object wrt static
>> initialization. Just because you claim that they do, does not make
>> it so.
>
> I've run the code with MSVC, libstdc++ and libc++, and with all
> implementations the code runs about a second, so there's no central
> mutex for all static initializations, but a mutex per static object.
> I've told that multiple times and you didn't understand that.
>
>

IF there is a Mutex per individual object, where is it? Show the call to
make them.

You are just makeing an ASS out of yourself (and not us) because you
ASS-U-ME about how it "must" work.

Just because you are too dense to see other options, doesn't mean they
don't exist.

Am 19.09.2023 um 13:48 schrieb Richard Damon:

> IF there is a Mutex per individual object, where is it? Show the call to
> make them.

I've proven that because multiple static initializations of
different objects run in parallel. Otherwise the code would
have run 100 seconds.
It makes sense to have a mutex per static object because with
that you can also have recursive static inizialization, which
would otherwise be not possible.

Am 19.09.2023 um 14:11 schrieb Bonita Montero:

> I've proven that because multiple static initializations of
> different objects run in parallel. Otherwise the code would
> have run 100 seconds.

I've extended the code to show that there are 100 different
static initializations per thread:

#include <iostream>
#include <utility>
#include <vector>
#include <thread>
#include <syncstream>

using namespace std;

int main()
{ struct InitSleep
{
InitSleep()
{
this_thread::sleep_for( 1s );
}
};
constexpr unsigned N_THREADS = 100;
auto unroll = []<size_t ... Indices>( index_sequence<Indices ...>, auto
fn )
{
(fn.template operator ()<Indices>(), ...);
};
vector<jthread> threads;
threads.reserve( N_THREADS );
unroll( make_index_sequence<N_THREADS>(),
[&]<size_t T>()
{
threads.emplace_back( []( auto )
{
static InitSleep is;
osyncstream( cout ) << (void *)&is << endl;
}, integral_constant<size_t, T>() );
} );
}

If you run the code you can see that each static object has a unique
address, different from each other.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 19.09.2023 um 07:01 schrieb Chris M. Thomasson:
>
>>> I've shown that static initialization actually uses a mutex per object.
>
>> Really?
>
>Here, a third time the code for you:

This code doesn't show any mutex at all.

Disassemble the code and find the synchronization object.

Am 19.09.2023 um 15:49 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 19.09.2023 um 07:01 schrieb Chris M. Thomasson:
>>
>>>> I've shown that static initialization actually uses a mutex per object.
>>
>>> Really?
>>
>> Here, a third time the code for you:
>
> This code doesn't show any mutex at all.

It is guaranteed that if multiple threads go through a line of code
with static initialization, only one thread will actually initialize
the static object and others will sleep meanwhile. This can't be
handled without something that works like a mutex. It is irrelevant
whether a std::mutex or a native mutex of the operating system is
used. Others here have understood that this is the only way it works,
the point of the discussion was simply whether exactly one mutex is
responsible for all static initializations, which would make it
possible to get through almost always without a malfunction, or
whether it would be more static Initialization there is a mutex.
I have proven the latter with my code.
So again: it is guaranteed that static initialization is thread-safe.
The standard also says that if more than one thread wants to initialize
statically, all others do not do so and ultimately sleep until the
initialization is complete. Please tell me how this should work
differently than with a mutex

> Disassemble the code and find the synchronization object.

Idiot.

On 2023-09-19, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 19.09.2023 um 13:48 schrieb Richard Damon:
>
>> IF there is a Mutex per individual object, where is it? Show the call to
>> make them.
>
> I've proven that because multiple static initializations of
> different objects run in parallel. Otherwise the code would
> have run 100 seconds.
> It makes sense to have a mutex per static object because with
> that you can also have recursive static inizialization, which
> would otherwise be not possible.

I don't suspect you can have a recursive initialization that isn't
erroneous.

If an object is in progress of being initialized, I think
the program must prevent the re-entry of that.

I'm surprised that you don't consider the possibility of
one mutex per "basic block":

Given:

{
static this x = f();
static that y = g();
// ...

}

why couldn't we have a single hidden mutex serializing both
initializations, rather than two mutexes?

If there is no conditional which separates the initialization of the
static objects, it seems they can be handled as an aggregate.

If there are separate mutexes for calling f() and g(), what
good does that do. If g() ends up recursing back to the above
scope, it will go past the x = f() initialization, which
is complete. That is well and good, but it will necessarily
hit the y = g() on also, which is bad.

There is no control flow branch which separates the two;
if one is executed, the other is.

What do you think?

--
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-19, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 19.09.2023 um 06:05 schrieb Kaz Kylheku:
>
>> You /seemed/ to be claiming that such an arrangement cannot deadlock.
>> Whether or not, I'm showing above how it can.
>> 1. One static initialization can be nested inside another,
>> such that the calling thread momentarily owns both mutexes.
>
> Then two mutexes are used.
>
>> 3. Thus, two threads can nest the same pair of initializations
>> in opposite order.
>
> If multiple mutexes are used that's actually not a problem.

Oh, it's a problem.

> And as I've shown there's a mutex per static initialization.

That's what creates the posssibility of deadlock. You do understand
that if two threads stepwise try to lock the same pair of mutexes in
opposite order, you get deadlock?

Thread A Thread B
| |
x.lock(); y.lock();
| |
y.lock() x.lock();

A is waiting for B to release y, which is waiting for A to release x.

You do understand that the mutex has to be held across
the initialization, right? Such that in "int x = f()",
the mutex is locked before we check the "__x_inited" flag.
If it is false, we call f(), update x, and then set __x_inited
true, and releases the mutex.

Thus, if initializations happen to nest, a thread can hold multiple
such mutexes.

This might not be a problem in the sense that if there is only one
thread, everything is fine, so that it's only a threads issue.

All the programs I can think of which trigger this problem also have a
problem if there exists just one thread doing all the initializing;
those repro programs dubiously recurse among initializations.

But, nevertheless, it's something that deadlock-detecting mutexes
could catch, whether for one thread, or multiple.

--
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 19.09.2023 um 18:41 schrieb Kaz Kylheku:

> I don't suspect you can have a recursive initialization that isn't
> erroneous.

Recursive initialization of static object simply works if you have
a mutex per object. I'm sure the standard requires that, otherwise
you'd run into problems. Actually the three mentioned implementations
support that because there's a mutex per objec.t

> If an object is in progress of being initialized, I think
> the program must prevent the re-entry of that.

That's a further flag.

> I'm surprised that you don't consider the possibility of
> one mutex per "basic block":

That's also a way to handle this, but I think the most elegant
way would be to have a lock-free stack of mutexes as a pool and
the mutex is given back to the pool by the last contender.

> why couldn't we have a single hidden mutex serializing both
> initializations, rather than two mutexes?

That's transparent if the standard handles it this way or not.

Am 19.09.2023 um 18:53 schrieb Kaz Kylheku:

> That's what creates the posssibility of deadlock. You do understand
> that if two threads stepwise try to lock the same pair of mutexes in
> opposite order, you get deadlock?
>
> Thread A Thread B
> | |
> x.lock(); y.lock();
> | |
> y.lock() x.lock();
>
> A is waiting for B to release y, which is waiting for A to release x.

Show me the code with static initialization that produces a deadlock.
That would be possible with nested initialization, but when you nest
you have always the same order, so this actually wouldn't give a
deadlock.

19.09.2023 19:55 Michael S kirjutas:
> On Tuesday, September 19, 2023 at 4:50:05 PM UTC+3, Scott Lurndal wrote:
>> Bonita Montero <Bonita....@gmail.com> writes:
>>> Am 19.09.2023 um 07:01 schrieb Chris M. Thomasson:
>>>
>>>>> I've shown that static initialization actually uses a mutex per object.
>>>
>>>> Really?
>>>
>>> Here, a third time the code for you:
>> This code doesn't show any mutex at all.
>>
>> Disassemble the code and find the synchronization object.
>
> I did a disassembling.
> https://godbolt.org/z/rM6Tf3Y87
>
> Bonita is correct in principle if not in details.
> May be she is correct in details too, I did not read all her posts.
>
> Compiler does emit one specialized mutex per static object.
> In case of LLVM such mutex consists of pair of 8-bit flags
> that appear to encode 3 or 4 possible states. The flags
> are updated under protection of global heavyweight mutex.
> Details can be found for example here:
> https://opensource.apple.com/source/libcppabi/libcppabi-14/src/cxa_guard.cxx
>
> I would think that other C++ compilers have similar mechanisms.

Nobody has denied there must be some synchronization in static
initialization. Bonita would be right only if there is some possibility
of failure when updating those flags.

Am 19.09.2023 um 20:11 schrieb Paavo Helde:

> Nobody has denied there must be some synchronization in static
> initialization. Bonita would be right only if there is some
> possibility of failure when updating those flags.

If the mutexes for all static initializations would be pre-created
before main() I'd nothing to complain. The creation can fail, the
synchronization can fail according to the API, but is actually
very unlikely.

On 9/19/2023 2:08 AM, Chris M. Thomasson wrote:
> On 9/19/2023 1:46 AM, Bonita Montero wrote:
>> Am 19.09.2023 um 07:01 schrieb Chris M. Thomasson:
>>
>>>> I've shown that static initialization actually uses a mutex per object.
>>
>>> Really?
>>
>> Here, a third time the code for you:
> [snip code]
>
> That does mean every impl must use a mutex per object wrt static
^^^^^^^^^^^^^^^^^^^^^

That does _not_ mean every

Damn typos!

> initialization. Just because you claim that they do, does not make it so.
>
>

On 9/19/2023 10:50 AM, Bonita Montero wrote:
> Am 19.09.2023 um 18:41 schrieb Kaz Kylheku:
>
>> I don't suspect you can have a recursive initialization that isn't
>> erroneous.
>
> Recursive initialization of static object simply works if you have
> a mutex per object. I'm sure the standard requires that, otherwise
> you'd run into problems. Actually the three mentioned implementations
> support that because there's a mutex per objec.t
>
>> If an object is in progress of being initialized, I think
>> the program must prevent the re-entry of that.
>
> That's a further flag.
>
>> I'm surprised that you don't consider the possibility of
>> one mutex per "basic block":
>
> That's also a way to handle this, but I think the most elegant
> way would be to have a lock-free stack of mutexes as a pool and
> the mutex is given back to the pool by the last contender.
>
>> why couldn't we have a single hidden mutex serializing both
>> initializations, rather than two mutexes?
>
> That's transparent if the standard handles it this way or not.
>

An impl can also decide to use futexes, that do not need to create a
mutex per static initialization.

On 9/19/2023 7:14 AM, Bonita Montero wrote:
> Am 19.09.2023 um 15:49 schrieb Scott Lurndal:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 19.09.2023 um 07:01 schrieb Chris M. Thomasson:
>>>
>>>>> I've shown that static initialization actually uses a mutex per
>>>>> object.
>>>
>>>> Really?
>>>
>>> Here, a third time the code for you:
>>
>> This code doesn't show any mutex at all.
>
> It is guaranteed that if multiple threads go through a line of code
> with static initialization, only one thread will actually initialize
> the static object and others will sleep meanwhile. This can't be
> handled without something that works like a mutex. It is irrelevant
> whether a std::mutex or a native mutex of the operating system is
> used. Others here have understood that this is the only way it works,
> the point of the discussion was simply whether exactly one mutex is
> responsible for all static initializations, which would make it
> possible to get through almost always without a malfunction, or
> whether it would be more static Initialization there is a  mutex.
> I have proven the latter with my code.
> So again: it is guaranteed that static initialization is thread-safe.
> The standard also says that if more than one thread wants to initialize
> statically, all others do not do so and ultimately sleep until the
> initialization is complete. Please tell me how this should work
> differently than with a mutex
>
>
>> Disassemble the code and find the synchronization object.
>
> Idiot.

Are you referring to yourself here? Just wondering.

On 9/19/2023 11:59 AM, Bonita Montero wrote:
> Am 19.09.2023 um 20:11 schrieb Paavo Helde:
>
>> Nobody has denied there must be some synchronization in static
>> initialization. Bonita would be right only if there is some
>> possibility of failure when updating those flags.
>
> If the mutexes for all static initializations would be pre-created
> before main() I'd nothing to complain. The creation can fail, the
> synchronization can fail according to the API, but is actually
> very unlikely.
>

Futex has all the kernel resources created up front, Bonita. Also, there
was this interesting method I learned about many years ago:

<pseudo-code>
_______________________
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
}

l_foo = t_foo;
}

else
{ // mb acquire
}

l_foo->bar();
_______________________

Its an interesting method to me.

On 9/19/2023 10:53 AM, Bonita Montero wrote:
> Am 19.09.2023 um 18:53 schrieb Kaz Kylheku:
>
>> That's what creates the posssibility of deadlock. You do understand
>> that if two threads stepwise try to lock the same pair of mutexes in
>> opposite order, you get deadlock?
>>
>>    Thread A                Thread B
>>       |                        |
>>    x.lock();                y.lock();
>>       |                        |
>>    y.lock()                 x.lock();
>>
>> A is waiting for B to release y, which is waiting for A to release x.
>
> Show me the code with static initialization that produces a deadlock.
> That would be possible with nested initialization, but when you nest
> you have always the same order, so this actually wouldn't give a
> deadlock.
>

A locking order is very important and must be enforced or deadlocks are
in your future... This is one reason why I sort the locks and remove
duplicates in my experimental multex:

https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/SkSqpSxGCAAJ

On 9/19/2023 1:43 AM, Bonita Montero wrote:
> Am 19.09.2023 um 07:01 schrieb Chris M. Thomasson:
>
>> We can choose to use the kernel to wait, if we choose to.
>> You are bringing back memories... Thanks for that Bonita. :^)
>
> The futex part of a mutex is for the slow path. It appears that
> this is done with a kernel intervention since there's no explicit
> kernel call.
>

A futex allows a programmer to use a predicate, akin to a condition
variable for lock/wait free algorithms. They are quite nice. Still, I
don't think you know how they actually work...

On 2023-09-19, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 19.09.2023 um 18:53 schrieb Kaz Kylheku:
>
>> That's what creates the posssibility of deadlock. You do understand
>> that if two threads stepwise try to lock the same pair of mutexes in
>> opposite order, you get deadlock?
>>
>> Thread A Thread B
>> | |
>> x.lock(); y.lock();
>> | |
>> y.lock() x.lock();
>>
>> A is waiting for B to release y, which is waiting for A to release x.
>
> Show me the code with static initialization that produces a deadlock.

Uh, check your "Rest unread" folder?

Here is a complete sample. When I compile it with "g++ -pthread" on
Unbutu 18, the ./a.out hangs.

In gdb, it's obvious that it's hanging in some sort of lock acquiring
operation.

int B();
int A();

int A()
{ static int a = B();
return 'A';
}

int B()
{ static int b = A();
return 'B';
}

int main()
{ A();
return 0;
}

$ g++ -Wall -pthread staticinit.cc
staticinit.cc: In function ‘int A()’:
staticinit.cc:6:14: warning: unused variable ‘a’ [-Wunused-variable]
static int a = B();
^
staticinit.cc: In function ‘int B()’:
staticinit.cc:12:14: warning: unused variable ‘b’ [-Wunused-variable]
static int b = A();
^
$ ./a.out
^C
$ gdb ./a.out
GNU gdb (Ubuntu 8.1.1-0ubuntu1) 8.1.1
[ ... ]
Reading symbols from ./a.out...(no debugging symbols found)...done.
(gdb) r
Starting program: /home/kaz/junk/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
^C
Program received signal SIGINT, Interrupt.
0xb7fd6d09 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fd6d09 in __kernel_vsyscall ()
#1 0xb7d07197 in syscall () at ../sysdeps/unix/sysv/linux/i386/syscall.S:29
#2 0xb7ea379d in __cxa_guard_acquire () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#3 0x004006c2 in A() ()
#4 0x00400773 in B() ()
#5 0x004006d7 in A() ()
#6 0x004007e5 in main ()
(gdb)

--
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/19/23 8:11 AM, Bonita Montero wrote:
> Am 19.09.2023 um 13:48 schrieb Richard Damon:
>
>> IF there is a Mutex per individual object, where is it? Show the call
>> to make them.
>
> I've proven that because multiple static initializations of
> different objects run in parallel. Otherwise the code would
> have run 100 seconds.
> It makes sense to have a mutex per static object because with
> that you can also have recursive static inizialization, which
> would otherwise be not possible.
>

Nope, all that shows is the system can't JUST use one global Mutex.

Your logic also shows that you don't understand how it actually works.

"Makes Sense" doesn't mean "Is True".

Your logic is as bad as PO's

On 9/19/23 10:14 AM, Bonita Montero wrote:
> Am 19.09.2023 um 15:49 schrieb Scott Lurndal:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 19.09.2023 um 07:01 schrieb Chris M. Thomasson:
>>>
>>>>> I've shown that static initialization actually uses a mutex per
>>>>> object.
>>>
>>>> Really?
>>>
>>> Here, a third time the code for you:
>>
>> This code doesn't show any mutex at all.
>
> It is guaranteed that if multiple threads go through a line of code
> with static initialization, only one thread will actually initialize
> the static object and others will sleep meanwhile. This can't be
> handled without something that works like a mutex. It is irrelevant
> whether a std::mutex or a native mutex of the operating system is
> used. Others here have understood that this is the only way it works,
> the point of the discussion was simply whether exactly one mutex is
> responsible for all static initializations, which would make it
> possible to get through almost always without a malfunction, or
> whether it would be more static Initialization there is a  mutex.
> I have proven the latter with my code.
> So again: it is guaranteed that static initialization is thread-safe.
> The standard also says that if more than one thread wants to initialize
> statically, all others do not do so and ultimately sleep until the
> initialization is complete. Please tell me how this should work
> differently than with a mutex
>
>
>> Disassemble the code and find the synchronization object.
>
> Idiot.

And there are things that work enough like a Mutex to do this, that
aren't Mutexes in the sense you are using, as they don't have the same
failure modes.

You are just showing how closed your mind is.

On 9/19/23 2:59 PM, Bonita Montero wrote:
> Am 19.09.2023 um 20:11 schrieb Paavo Helde:
>
>> Nobody has denied there must be some synchronization in static
>> initialization. Bonita would be right only if there is some
>> possibility of failure when updating those flags.
>
> If the mutexes for all static initializations would be pre-created
> before main() I'd nothing to complain. The creation can fail, the
> synchronization can fail according to the API, but is actually
> very unlikely.
>

So, you didn't read the explaination of how it was actually done.

I guess that shows your level of literacy.

On 9/19/2023 3:45 PM, Richard Damon wrote:
> On 9/19/23 10:14 AM, Bonita Montero wrote:
>> Am 19.09.2023 um 15:49 schrieb Scott Lurndal:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>> Am 19.09.2023 um 07:01 schrieb Chris M. Thomasson:
>>>>
>>>>>> I've shown that static initialization actually uses a mutex per
>>>>>> object.
>>>>
>>>>> Really?
>>>>
>>>> Here, a third time the code for you:
>>>
>>> This code doesn't show any mutex at all.
>>
>> It is guaranteed that if multiple threads go through a line of code
>> with static initialization, only one thread will actually initialize
>> the static object and others will sleep meanwhile. This can't be
>> handled without something that works like a mutex. It is irrelevant
>> whether a std::mutex or a native mutex of the operating system is
>> used. Others here have understood that this is the only way it works,
>> the point of the discussion was simply whether exactly one mutex is
>> responsible for all static initializations, which would make it
>> possible to get through almost always without a malfunction, or
>> whether it would be more static Initialization there is a  mutex.
>> I have proven the latter with my code.
>> So again: it is guaranteed that static initialization is thread-safe.
>> The standard also says that if more than one thread wants to initialize
>> statically, all others do not do so and ultimately sleep until the
>> initialization is complete. Please tell me how this should work
>> differently than with a mutex
>>
>>
>>> Disassemble the code and find the synchronization object.
>>
>> Idiot.
>
> And there are things that work enough like a Mutex to do this, that
> aren't Mutexes in the sense you are using, as they don't have the same
> failure modes.
>
> You are just showing how closed your mind is.

An example of Bonita thinking along wrt everything must exactly adhere
to her certain way... Anything the disagrees with this must be an
idiotic moron?

https://youtu.be/WzSai5qtHr8

;^)