Bonita Montero wrote:
> Am 17.09.2023 um 22:01 schrieb Pavel:
>
>> Of course you don't show that the synchronization primitives that are
>> used for static initialization are mutexes.
>
> Call it mutex or whatever: the standard requires that contenders
> sleep in place, and that's only possible with something that works
> like a mutex.
Define "works like a mutex".

On 9/18/23 8:37 AM, Bonita Montero wrote:
> Am 18.09.2023 um 14:13 schrieb Richard Damon:
>
>> Why?
>
> Because a mutex does this also with an appropriate exception. And there
> wouldn't be more problems if such an excepton would be thrown, but less.
>

So implementions needs to be allowed to do the wrong thing?

Shows your sense of how programs shoudld (not) work.

>> Since it can be done without ever failing, ...
>
> I've shown that libc++, libstdc++ and MSVC handle this with per-object
> mutexes, and if you create an arbitrary number of mutexes this might
> fail.
>
>

Nope. You show that you can not read.

Others have pointed out what the code of those functions ACTUALLY do, an
it isn't what you are calling a "Mutex", and it can't fail.

Am 18.09.2023 um 21:21 schrieb Chris M. Thomasson:
> On 9/17/2023 10:05 PM, Bonita Montero wrote:
>> Am 17.09.2023 um 21:57 schrieb Chris M. Thomasson:
>>
>>> I still don't think you know how they work.
>>
>> You didn't read the paper, not me.
>>
>
> I already know how futexes work. In and out.

You said that everythong happens in userspace. And you didn't notice
that it isn't impossible to have a blocking thread this way ...

Am 19.09.2023 um 02:15 schrieb Pavel:

> Or, when there is nothing to create, there is nothing to defer,

I've shown that static initialization actually uses a mutex per object.
The runtimes for sure not pre-create a number of mutexes for that since
static objects are just zeroed memory before initialization.

Am 18.09.2023 um 21:22 schrieb Chris M. Thomasson:
> On 9/17/2023 10:07 PM, 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.
>
> The impl must make sure to get it right wrt static initialization.

Idiot - I wasn't talking about static initialization at this point.

Am 19.09.2023 um 03:04 schrieb Richard Damon:

> So implementions needs to be allowed to do the wrong thing?

It would be the right thing if this would be specified.

> Others have pointed out what the code of those functions ACTUALLY do,
> an it isn't what you are calling a "Mutex", and it can't fail.

You're as stupid as Chris - I wasn't talking about whether the code
can fail or not at this point, but just that there's actually a mutex
per static object.

Am 18.09.2023 um 21:42 schrieb Kaz Kylheku:

>> Local static objects are initialized when the code comes across the
>> initialization. All other static local objects it refers to have been
>> declared before, otherwise the static object wouldn't be able to use
>> them. So there will be never a deadlock.

> That is false:
>
> struct static_thing
> {
> // constructor calls function pointer argument
> static_thing(void (*)(pfn))
> {
> pfn();
> }
> };
>
> void A(void)
> {
> static_thing o(B);
> }
>
> void B(void)
> {
> static_thing o(A);
> }
> ...

That doesn't make sense in the context since we talked about
a deadlock by the mutex included in static initialization and
not by mutexes you handle separarely - idiot.

Am 19.09.2023 um 02:30 schrieb Pavel:

>> Call it mutex or whatever: the standard requires that contenders
>> sleep in place, and that's only possible with something that works
>> like a mutex.

> Define "works like a mutex".

A lock which makes a thread to sleep on contention.

On 2023-09-19, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 18.09.2023 um 21:42 schrieb Kaz Kylheku:
>
>>> Local static objects are initialized when the code comes across the
>>> initialization. All other static local objects it refers to have been
>>> declared before, otherwise the static object wouldn't be able to use
>>> them. So there will be never a deadlock.
>
>> That is false:
>>
>> struct static_thing
>> {
>> // constructor calls function pointer argument
>> static_thing(void (*)(pfn))
>> {
>> pfn();
>> }
>> };
>>
>> void A(void)
>> {
>> static_thing o(B);
>> }
>>
>> void B(void)
>> {
>> static_thing o(A);
>> }
>> ...
>
> That doesn't make sense in the context since we talked about
> a deadlock by the mutex included in static initialization and
> not by mutexes you handle separarely - idiot.

The subject of the thread is "Thread-safe initialization of static
objects". This is what I'm writing about. I have static objects
above (which don't have mutexes, or any data members at all). I'm
assuming their initialization is made thread-safe via (hidden, not
explicitly visible) mutexes generated by the compiler.

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.

2. Two or more threads can execute initializations.

3. Thus, two threads can nest the same pair of initializations
in opposite order.

(Therefore, I agree with you; those hidden mutexes could run into
a situation which their lock operations could, in principle, detect
and turn into an exception.)

If you didn't claim that static initialization with hidden mutexes
cannot deadlock, please disregard this as a counterexample to anything
you said, but it still holds on its own.

--
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/18/2023 8:08 PM, Bonita Montero wrote:
> Am 18.09.2023 um 21:21 schrieb Chris M. Thomasson:
>> On 9/17/2023 10:05 PM, Bonita Montero wrote:
>>> Am 17.09.2023 um 21:57 schrieb Chris M. Thomasson:
>>>
>>>> I still don't think you know how they work.
>>>
>>> You didn't read the paper, not me.
>>>
>>
>> I already know how futexes work. In and out.
>
> You said that everythong happens in userspace. And you didn't notice
> that it isn't impossible to have a blocking thread this way ...
>
>

We can choose to use the kernel to wait, if we choose to. You are
bringing back memories... Thanks for that Bonita. :^)

On 9/18/2023 8:10 PM, Bonita Montero wrote:
> Am 19.09.2023 um 02:15 schrieb Pavel:
>
>> Or, when there is nothing to create, there is nothing to defer,
>
> I've shown that static initialization actually uses a mutex per object.

Really?

> The runtimes for sure not pre-create a number of mutexes for that since
> static objects are just zeroed memory before initialization.
>

On 9/18/2023 8:11 PM, Bonita Montero wrote:
> Am 18.09.2023 um 21:22 schrieb Chris M. Thomasson:
>> On 9/17/2023 10:07 PM, 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.
>>
>> The impl must make sure to get it right wrt static initialization.
>
> Idiot - I wasn't talking about static initialization at this point.
>

Oh, I think you are. Are you now talking about how many mutexes can a
process create before it dies?

On 9/18/2023 8:14 PM, Bonita Montero wrote:
> Am 19.09.2023 um 03:04 schrieb Richard Damon:
>
>> So implementions needs to be allowed to do the wrong thing?
>
> It would be the right thing if this would be specified.
>
>> Others have pointed out what the code of those functions ACTUALLY do,
>> an it isn't what you are calling a "Mutex", and it can't fail.
>
> You're as stupid as Chris - I wasn't talking about whether the code
> can fail or not at this point,

Altering goal posts now, oh wonderful one?

> but just that there's actually a mutex
> per static object.
>

Really? Humm...

On 9/18/2023 9:05 PM, Kaz Kylheku wrote:
> On 2023-09-19, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 18.09.2023 um 21:42 schrieb Kaz Kylheku:
>>
>>>> Local static objects are initialized when the code comes across the
>>>> initialization. All other static local objects it refers to have been
>>>> declared before, otherwise the static object wouldn't be able to use
>>>> them. So there will be never a deadlock.
>>
>>> That is false:
>>>
>>> struct static_thing
>>> {
>>> // constructor calls function pointer argument
>>> static_thing(void (*)(pfn))
>>> {
>>> pfn();
>>> }
>>> };
>>>
>>> void A(void)
>>> {
>>> static_thing o(B);
>>> }
>>>
>>> void B(void)
>>> {
>>> static_thing o(A);
>>> }
>>> ...
>>
>> That doesn't make sense in the context since we talked about
>> a deadlock by the mutex included in static initialization and
>> not by mutexes you handle separarely - idiot.
>
> The subject of the thread is "Thread-safe initialization of static
> objects". This is what I'm writing about. I have static objects
> above (which don't have mutexes, or any data members at all). I'm
> assuming their initialization is made thread-safe via (hidden, not
> explicitly visible) mutexes generated by the compiler.
>
> You /seemed/ to be claiming that such an arrangement cannot deadlock.

If the impl can deadlock wrt satic init, then we might as well take an
infinite walk off a very short peer.

>
> 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.
>
> 2. Two or more threads can execute initializations.
>
> 3. Thus, two threads can nest the same pair of initializations
> in opposite order.
>
> (Therefore, I agree with you; those hidden mutexes could run into
> a situation which their lock operations could, in principle, detect
> and turn into an exception.)
>
> If you didn't claim that static initialization with hidden mutexes
> cannot deadlock, please disregard this as a counterexample to anything
> you said, but it still holds on its own.
>

On 9/18/2023 10:08 PM, Chris M. Thomasson wrote:
> On 9/18/2023 9:05 PM, Kaz Kylheku wrote:
>> On 2023-09-19, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 18.09.2023 um 21:42 schrieb Kaz Kylheku:
>>>
>>>>> Local static objects are initialized when the code comes across the
>>>>> initialization. All other static local objects it refers to have been
>>>>> declared before, otherwise the static object wouldn't be able to use
>>>>> them. So there will be never a deadlock.
>>>
>>>> That is false:
>>>>
>>>>     struct static_thing
>>>>     {
>>>>       // constructor calls function pointer argument
>>>>       static_thing(void (*)(pfn))
>>>>       {
>>>>          pfn();
>>>>       }
>>>>     };
>>>>
>>>>     void A(void)
>>>>     {
>>>>        static_thing o(B);
>>>>     }
>>>>
>>>>     void B(void)
>>>>     {
>>>>        static_thing o(A);
>>>>     }
>>>> ...
>>>
>>> That doesn't make sense in the context since we talked about
>>> a deadlock by the mutex included in static initialization and
>>> not by mutexes you handle separarely - idiot.
>>
>> The subject of the thread is "Thread-safe initialization of static
>> objects". This is what I'm writing about. I have static objects
>> above (which don't have mutexes, or any data members at all). I'm
>> assuming their initialization is made thread-safe via (hidden, not
>> explicitly visible) mutexes generated by the compiler.
>>
>> You /seemed/ to be claiming that such an arrangement cannot deadlock.
>
> If the impl can deadlock wrt satic init, then we might as well take an
> infinite walk off a very short peer.
>
>>
>> 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.

>>
>> 2. Two or more threads can execute initializations.
>>
>> 3. Thus, two threads can nest the same pair of initializations
>>     in opposite order.
>>
>> (Therefore, I agree with you; those hidden mutexes could run into
>> a situation which their lock operations could, in principle, detect
>> and turn into an exception.)
>>
>> If you didn't claim that static initialization with hidden mutexes
>> cannot deadlock, please disregard this as a counterexample to anything
>> you said, but it still holds on its own.
>>
>

The impl better sure make god damn sure that there is no deadlock on
static init of say, POD's.

On 9/18/2023 8:17 PM, Bonita Montero wrote:
> Am 19.09.2023 um 02:30 schrieb Pavel:
>
>>> Call it mutex or whatever: the standard requires that contenders
>>> sleep in place, and that's only possible with something that works
>>> like a mutex.
>
>> Define "works like a mutex".
>
> A lock which makes a thread to sleep on contention.
>

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.

On 9/18/2023 8:08 PM, Bonita Montero wrote:
> Am 18.09.2023 um 21:21 schrieb Chris M. Thomasson:
>> On 9/17/2023 10:05 PM, Bonita Montero wrote:
>>> Am 17.09.2023 um 21:57 schrieb Chris M. Thomasson:
>>>
>>>> I still don't think you know how they work.
>>>
>>> You didn't read the paper, not me.
>>>
>>
>> I already know how futexes work. In and out.
>
> You said that everythong happens in userspace.

Any user algorithm that needs to be able to wait on a predicate. Futex!

> And you didn't notice
> that it isn't impossible to have a blocking thread this way ...
>
>

On 2023-09-19, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> The impl better sure make god damn sure that there is no deadlock on
> static init of say, POD's.

PODs aren't a special category. Never mind that, how about scalars?

The problem is that the static initializer expressions in C++ can call
functions.

int B();

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

void B()
{
static int b = A();
}

What prevents a deadlock here, in mutex-guarded static initialization
logic, if one thread calls A at the same time as another calls B?

Here is one way a deadlock could be prevented, at least in a program
which doesn't mix its own explicit mutexes with static initializations:
just have one global mutex (a recursive one) for all lazy static
initializations.

--
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/18/2023 10:50 PM, Kaz Kylheku wrote:
> On 2023-09-19, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> The impl better sure make god damn sure that there is no deadlock on
>> static init of say, POD's.
>
> PODs aren't a special category. Never mind that, how about scalars?
>
> The problem is that the static initializer expressions in C++ can call
> functions.
>
> int B();
>
> int A()
> {
>     static int a = B();
> }
>
> void B()
> {
> static int b = A();
> }
>
> What prevents a deadlock here, in mutex-guarded static initialization
> logic, if one thread calls A at the same time as another calls B?
>
> Here is one way a deadlock could be prevented, at least in a program
> which doesn't mix its own explicit mutexes with static initializations:
> just have one global mutex (a recursive one) for all lazy static
> initializations.
>

A allowing recursion would work, but I tend to try to avoid those suckers.

On 9/18/2023 10:50 PM, Kaz Kylheku wrote:
> On 2023-09-19, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> The impl better sure make god damn sure that there is no deadlock on
>> static init of say, POD's.
>
> PODs aren't a special category. Never mind that, how about scalars?
>
> The problem is that the static initializer expressions in C++ can call
> functions.
>
> int B();
>
> int A()
> {
>     static int a = B();
> }
>
> void B()
> {
> static int b = A();
> }

Would that go into infinite recursion?

>
> What prevents a deadlock here, in mutex-guarded static initialization
> logic, if one thread calls A at the same time as another calls B?
>
> Here is one way a deadlock could be prevented, at least in a program
> which doesn't mix its own explicit mutexes with static initializations:
> just have one global mutex (a recursive one) for all lazy static
> initializations.
>

On 2023-09-19, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 9/18/2023 10:50 PM, Kaz Kylheku wrote:
>> On 2023-09-19, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> The impl better sure make god damn sure that there is no deadlock on
>>> static init of say, POD's.
>>
>> PODs aren't a special category. Never mind that, how about scalars?
>>
>> The problem is that the static initializer expressions in C++ can call
>> functions.
>>
>> int B();
>>
>> int A()
>> {
>>     static int a = B();
>> }
>>
>> void B()
>> {
>> static int b = A();
>> }
>
> Would that go into infinite recursion?

Firstly, I also wanted an int return on B() and return statements.

Yes; even in a single threaded situation, we have a recursion problem.
So that's the overriding problem, not whether we get deadlock with
multiple threads.

If the one and only thread calls A(), it will re-enter A() without
the initialization having completed which is bad.

Can you think of some static init scenario that works fine single
threaded, but potentially deadlocks when threads are present?

Even if not, be that as it may, the mutex deadlock detection could
debug the situation, whether just one thread triggers it, or
several.

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

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:

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

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;
}, integral_constant<size_t, T>() );
} );
}

The lambda's calling operator is instantiated N_THREADS time, thereby
having a static object per calling operator. If there would be a central
mutex for all static initializations the code would run about 100s, but
it actually finishes after one second.

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.
And as I've shown there's a mutex per static initialization.

Rest unread.

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

> If the impl can deadlock wrt satic init, then we might as well take an
> infinite walk off a very short peer.

If one object depens on an initialization of another before there's
no dependent locking. If one static inizialization is nested inside
another there's also no dependent locking since the nested object
has its own mutex.