With C++11 static local or global data is initialized thread-safe.
This is usually done with double checked locking (DCL). DCL needs
a flag along with the static data which shows if the data already
is initialized and a mutex which guards the initalization.
I assumed that an implementation simply would use a central mutex
for all static data objects since it includes a kernel semaphore,
which is a costly resource.
To find out if this is true I wrote the below application:

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

using namespace std;

template<unsigned Thread>
struct SleepAtInitialize
{ SleepAtInitialize()
{
this_thread::sleep_for( 1s );
}
};

int main()
{ auto unroll = []<size_t ... Indices>( index_sequence<Indices ...>, auto
fn )
{
((fn.template operator ()<Indices>()), ...);
};
constexpr unsigned N_THREADS = 10;
vector<jthread> threads;
threads.reserve( N_THREADS );
unroll( make_index_sequence<N_THREADS>(),
[&]<unsigned Thread>()
{
threads.emplace_back( [&]<unsigned IObj>(integral_constant<unsigned,
IObj> )
{
static SleepAtInitialize<IObj> guard;
}, integral_constant<unsigned, Thread>() );
} );

}

SleepAtInitialize<IObj> is instantiated only once per thread with this
code. So the threads don't share a central object. If there would be
a central mutex used the above code would run for about 10s. But the
code does run about one second, i.e. there are indivual mutexes per
each instantiation of SleepAtInitiaize<>. I.e. the creation of the
mutex is also done with the static initialization. The mutex constructor
is noexcept, so mutexes always must be created on their first use. This
is done while the DCL-locked creation of the static object. So at last
static initialization should be declared to throw a system_errror. But
I can't find anything about that in the standard.

Bonita Montero wrote:
> With C++11 static local or global data is initialized thread-safe.
> This is  usually done with double checked locking (DCL). DCL needs
> a flag along with the static data which shows if the data already
> is initialized and a mutex which guards the initalization.
Not needed. A test-and-set instruction on a flag -- that is itself
constant-initialized -- is sufficient.

> I assumed that an implementation simply would use a central mutex
> for all static data objects since it includes a kernel semaphore,
> which is a costly resource.
> To find out if this is true I wrote the below application:
>
> #include <iostream>
> #include <thread>
> #include <vector>
>
> using namespace std;
>
> template<unsigned Thread>
> struct SleepAtInitialize
> {
>     SleepAtInitialize()
>     {
>         this_thread::sleep_for( 1s );
>     }
> };
>
> int main()
> {
>     auto unroll = []<size_t ... Indices>( index_sequence<Indices ...>,
> auto fn )
>     {
>         ((fn.template operator ()<Indices>()), ...);
>     };
>     constexpr unsigned N_THREADS = 10;
>     vector<jthread> threads;
>     threads.reserve( N_THREADS );
>     unroll( make_index_sequence<N_THREADS>(),
>         [&]<unsigned Thread>()
>         {
>             threads.emplace_back( [&]<unsigned
> IObj>(integral_constant<unsigned, IObj> )
>                 {
>                     static SleepAtInitialize<IObj> guard;
>                 }, integral_constant<unsigned, Thread>() );
>         } );
>
> }
>
> SleepAtInitialize<IObj> is instantiated only once per thread with this
> code. So the threads don't share a central object. If there would be
> a central mutex used the above code would run for about 10s. But the
> code does run about one second, i.e. there are indivual mutexes per
> each instantiation of SleepAtInitiaize<>. I.e. the creation of the
> mutex is also done with the static initialization. The mutex constructor
> is noexcept, so mutexes always must be created on their first use. This
> is done while the DCL-locked creation of the static object. So at last
> static initialization should be declared to throw a system_errror. But
> I can't find anything about that in the standard.

Am 07.09.2023 um 00:44 schrieb Pavel:
> Bonita Montero wrote:
>> With C++11 static local or global data is initialized thread-safe.
>> This is  usually done with double checked locking (DCL). DCL needs
>> a flag along with the static data which shows if the data already
>> is initialized and a mutex which guards the initalization.

> Not needed. A test-and-set instruction on a flag -- that is itself
> constant-initialized -- is sufficient.

Using only one flag would require spin-locking. However, spin-locking
is not possible in userspace because a thread holding a spinlock could
keep other threads spinning for a long time. Therefore, there is no
getting around a solution with a mutex. And creation and mutex synchro-
nization may fail.

Bonita Montero wrote:
> Am 07.09.2023 um 00:44 schrieb Pavel:
>> Bonita Montero wrote:
>>> With C++11 static local or global data is initialized thread-safe.
>>> This is  usually done with double checked locking (DCL). DCL needs
>>> a flag along with the static data which shows if the data already
>>> is initialized and a mutex which guards the initalization.
>
>> Not needed. A test-and-set instruction on a flag -- that is itself
>> constant-initialized -- is sufficient.
>
> Using only one flag would require spin-locking. However, spin-locking
> is not possible in userspace
not true, a loop with yield in the body is very possible.

> because a thread holding a spinlock could
> keep other threads spinning for a long time. Therefore, there is no
> getting around a solution with a mutex.
does not have to be a mutex, can be call_once, a semaphore, anything,
actually.

> And creation and mutex synchro-
> nization may fail.
If initialization synchronization fails, the initialization can catch
and terminate. No need to throw a system error. No need to use C++
synchronization primitives in the initialization code either; nothing
prevents the implementation from being implemented in a
platform-specific manner.

Am 07.09.2023 um 06:18 schrieb Pavel:

> not true, a loop with yield in the body is very possible.

No one would accept that because that would make the waiters to wait
much more longer than necessary.

> does not have to be a mutex, can be call_once, a semaphore, anything,
> actually.

Every applicable facility for that would rely on kernel-synchronization.
You'd need to create a binary semaphore for that and you need so syn-
chronize on that; both may fail.

> If initialization synchronization fails, the initialization can catch
> and terminate. ...

Nothing like that is specified.

On 9/6/2023 3:44 PM, Pavel wrote:
> Bonita Montero wrote:
>> With C++11 static local or global data is initialized thread-safe.
>> This is  usually done with double checked locking (DCL). DCL needs
>> a flag along with the static data which shows if the data already
>> is initialized and a mutex which guards the initalization.
> Not needed. A test-and-set instruction on a flag -- that is itself
> constant-initialized -- is sufficient.
[...]

You also need to use the appropriate memory barriers. An acquire after
the first check, and a release before making the object visible.

// pseudo code, its been a while.
// Damn, I used to work with threads all of the time.
___________________________
static foo* g_foo = nullptr;

foo* local = g_foo; // atomic load

if (! local)
{ hash_lock(&g_foo);

local = g_foo; // atomic load

if (! local)
{
local = new foo;

// release mb #LoadStore | #StoreStore

g_foo = local; // atomic store

}

else
{
// acquire mb #LoadStore | #LoadLoad
}

hash_unlock(&g_foo);
}

else
{ // acquire mb #LoadStore | #LoadLoad
}

local->foobar();
___________________________

Iirc, that is a bare bones DCL.

Am 07.09.2023 um 08:33 schrieb Chris M. Thomasson:

> You also need to use the appropriate memory barriers. ...
That's all inside the Wikipedia example about DCL. But the discussion
was about whether the thead safe-initialization may fail before or
after the object's constructor is called because the mutex creation
or the kernel-synchronization may fail.

On 9/6/2023 11:53 PM, Bonita Montero wrote:
> Am 07.09.2023 um 08:33 schrieb Chris M. Thomasson:
>
>> You also need to use the appropriate memory barriers. ...
> That's all inside the Wikipedia example about DCL. But the discussion
> was about whether the thead safe-initialization may fail before or
> after the object's constructor is called because the mutex creation
> or the kernel-synchronization may fail.

Usually, the hash table of mutexes is created before any of the programs
logic is executed...

06.09.2023 21:15 Bonita Montero kirjutas:
> With C++11 static local or global data is initialized thread-safe.
> This is  usually done with double checked locking (DCL). DCL needs
> a flag along with the static data which shows if the data already
> is initialized and a mutex which guards the initalization.
> I assumed that an implementation simply would use a central mutex
> for all static data objects since it includes a kernel semaphore,
> which is a costly resource.
> To find out if this is true I wrote the below application:
[...]
> SleepAtInitialize<IObj> is instantiated only once per thread with this
> code. So the threads don't share a central object. If there would be
> a central mutex used the above code would run for about 10s. But the
> code does run about one second,

There is a note in the standard: "[Note: This definition permits
initialization of a sequence of ordered variables concurrently with
another sequence. —end note]"

i.e. there are indivual mutexes per
> each instantiation of SleepAtInitiaize<>. I.e. the creation of the
> mutex is also done with the static initialization. The mutex constructor
> is noexcept, so mutexes always must be created on their first use. This
> is done while the DCL-locked creation of the static object. So at last
> static initialization should be declared to throw a system_errror. But
> I can't find anything about that in the standard.

Some debugging with VS2022 seems to indicate it is using a Windows
critical section for thread-safe statics initialization.
EnterCriticalSection() does not return any error code and of course does
not throw any C++ exceptions either, so it is supposed to never fail.

Yes, it's true it can throw a Windows structured exception
EXCEPTION_POSSIBLE_DEADLOCK (after 30 days by default). But this would
be considered as a fault in the program. This is what the C++ standard
says about deadlocks (again a footnote):

"The implementation must not introduce any deadlock around execution of
the initializer. Deadlocks might still be caused by the program logic;
the implementation need only avoid deadlocks due to its own
synchronization operations."

So I gather that in case the thread-safe static init synchronization
fails, there must be a bug in the implementation. No C++ exceptions
would be thrown anyway.

Am 07.09.2023 um 09:16 schrieb Chris M. Thomasson:

> Usually, the hash table of mutexes is created before
> any of the programs logic is executed...

That sounds too complex for me. Creating individual mutexes on
demand would be o.k. and I think a lock-free stack with a pool
of mutexes would be fancy. A hashtable is too slow for that.

Bonita Montero wrote:
> Am 07.09.2023 um 06:18 schrieb Pavel:
>
>> not true, a loop with yield in the body is very possible.
>
> No one would accept that because that would make the waiters to wait
> much more longer than necessary.
How so? Waiters will wait for the time of initialization. The
initializing thread will be yielded to and receive virtually as many and
as complete time slices as it would under any other scheduling
discipline so it will complete its job in same or virtually same time
(actually, the higher system contention level is the more efficient
user-space waiting with yield becomes). Hence the time waiters will wait
is exactly or virtually same as when using mutex.

Also it should be taken into account that all above (and below) is only
relevant to the rare case when the initialization is contended; in other
words, "no one would accept" would be an exaggeration of the year even
if your speculation on "wait much longer" were true -- which it isn't.

>
>> does not have to be a mutex, can be call_once, a semaphore, anything,
>> actually.
>
> Every applicable facility for that would rely on kernel-synchronization.
> You'd need to create a binary semaphore for that and you need so syn-
> chronize on that; both may fail.
try_lock in a loop with a sleep or yield wouldn't fail. But as said
above, it's not needed.

Regardless, your argument assumes too much C++-morphism in the
implementation whereas the implementation can use any platform-specific
approach available to it. E.g. pthread_once on Linux does not fail if
given valid arguments (which C++ implementation can provide). Other
platforms may have tools of their own to do the job.

>
>> If initialization synchronization fails, the initialization can catch
>> and terminate. ...
>
> Nothing like that is specified.
Correct, the above was wrong. But initialization can catch and try
again. This does not have to be specified as it is not observable from
outside.

Am 07.09.2023 um 16:44 schrieb Pavel:

> How so? Waiters will wait for the time of initialization.
> The initializing thread will be yielded ...

Initializing is usually much faster than a whole timeslice,
so yielding would be incacceptabel. That's just a stupid idea.

> try_lock in a loop with a sleep or yield wouldn't fail. ...

Do you really think someone would accept spinning with that ?
This means that an initializing thread which is scheduled away
while holding the mutex might keep other threads spinning for
a long time.

> Regardless, your argument assumes too much C++-morphism in the
> implementation whereas the implementation can use any platform
> -specific approach available to it. E.g. pthread_once on Linux
> does not fail if given valid arguments ...

pthread_once could be implemented with a single central semaphore for
all operations and if the implementers know that the synchronization
itself doesn't fail and the semphore is pre-allocated by the runtime
it's possible to survive that synchronization without error.
But check that code:

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

using namespace std;

template<unsigned Thread>
struct SleepAtInitialize
{ SleepAtInitialize()
{
this_thread::sleep_for( 1s );
}
};

int main()
{ auto unroll = []<size_t ... Indices>( index_sequence<Indices ...>, auto
fn )
{
((fn.template operator ()<Indices>()), ...);
};
constexpr unsigned N_THREADS = 10;
vector<jthread> threads;
threads.reserve( N_THREADS );
unroll( make_index_sequence<N_THREADS>(),
[&]<unsigned Thread>()
{
threads.emplace_back(
[&]<unsigned IObj>( integral_constant<unsigned, IObj> )
{
static SleepAtInitialize<IObj> guard;
}, integral_constant<unsigned, Thread>() );
} );

}

This code runs with individual mutexes per object, i.e. the time
taken is about one second (with MSVC, libc++ and libstdc++). So
when individual mutexes are used the initialization may fail.

> Correct, the above was wrong. But initialization can catch and try
> again. ...

That a bumbler solution.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 07.09.2023 um 16:44 schrieb Pavel:
>
>> How so? Waiters will wait for the time of initialization.
>> The initializing thread will be yielded ...
>
>Initializing is usually much faster than a whole timeslice,
>so yielding would be incacceptabel. That's just a stupid idea.

So tell us, on which operating systems will there be more than
one thread running when application static objects are
initialized (which happens generally before the application
'main' function is called, and thus before the application
has a chance to create any threads)?

On 9/7/23 10:27 AM, Scott Lurndal wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 07.09.2023 um 16:44 schrieb Pavel:
>>
>>> How so? Waiters will wait for the time of initialization.
>>> The initializing thread will be yielded ...
>>
>> Initializing is usually much faster than a whole timeslice,
>> so yielding would be incacceptabel. That's just a stupid idea.
>
> So tell us, on which operating systems will there be more than
> one thread running when application static objects are
> initialized (which happens generally before the application
> 'main' function is called, and thus before the application
> has a chance to create any threads)?

While GLOBAL static objects get initialized before main starts, function
local static objects don't get initialized until the first call of the
function. These will need some synchronization if the function is called
from multiple threads at "the same time".

Also, some global object could start up a thread in its constructor.

Am 07.09.2023 um 19:27 schrieb Scott Lurndal:

> So tell us, on which operating systems will there be more
> than one thread running when application static objects are
> initialized (which happens generally before the application
> 'main' function is called, and thus before the application
> has a chance to create any threads)?

I've shown with my code that each static object gets its own mutex
with MSVC, libstdc++ and libc++. Here it is again in a simplified
version:

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

using namespace std;

int main()
{ struct SleepAtInitialize
{
SleepAtInitialize()
{
this_thread::sleep_for( 1s );
}
};
auto unroll = []<size_t ... Indices>( index_sequence<Indices ...>, auto
fn )
{
((fn.template operator ()<Indices>()), ...);
};
constexpr unsigned N_THREADS = 10;
vector<jthread> threads;
threads.reserve( N_THREADS );
unroll( make_index_sequence<N_THREADS>(),
[&]<unsigned Thread>()
{
threads.emplace_back(
[&]<unsigned IObj>( integral_constant<unsigned, IObj> )
{
static SleepAtInitialize guard;
}, integral_constant<unsigned, Thread>() );
} );

}

The code runs about one second with all three implementations,
so ther's a mutex per statically initialized object.

On 9/7/2023 5:17 AM, Bonita Montero wrote:
> Am 07.09.2023 um 09:16 schrieb Chris M. Thomasson:
>
>> Usually, the hash table of mutexes is created before
>> any of the programs logic is executed...
>
> That sounds too complex for me. Creating individual mutexes on
> demand would be o.k. and I think a lock-free stack with a pool
> of mutexes would be fancy. A hashtable is too slow for that.
>
>

No. A simple hash of a pointer into an index works out okay, not too
slow at all. Fwiw, check this out, tell me what you think:

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

It is a quick and crude example simulation of one way to do it. The hash
lock table is created before program logic is executed.

Any thoughts?

Also, we are talking about a slow path wrt DCL.

On 9/7/2023 11:06 AM, Richard Damon wrote:
> On 9/7/23 10:27 AM, Scott Lurndal wrote:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 07.09.2023 um 16:44 schrieb Pavel:
>>>
>>>> How so? Waiters will wait for the time of initialization.
>>>> The initializing thread will be yielded ...
>>>
>>> Initializing is usually much faster than a whole timeslice,
>>> so yielding would be incacceptabel. That's just a stupid idea.
>>
>> So tell us, on which operating systems will there be more than
>> one thread running when application static objects are
>> initialized (which happens generally before the application
>> 'main' function is called, and thus before the application
>> has a chance to create any threads)?
>
> While GLOBAL static objects get initialized before main starts, function
> local static objects don't get initialized until the first call of the
> function. These will need some synchronization if the function is called
> from multiple threads at "the same time".

A simple global hash lock scheme is where we can hash addresses directly
into a static locking table. The lock table is created _before_ any
program logic is executed.

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

> Also, some global object could start up a thread in its constructor.

YIKES! Shit. I have had to debug other peoples code that did this. Many
points of errors... One was a rather common peach of a bug. The
constructor would create a thread that would in turn call into a virtual
function and start using the object before its constructor was
completed. A massive race condition, nasty ones!

Am 07.09.2023 um 21:06 schrieb Chris M. Thomasson:

> No. A simple hash of a pointer into an index works out okay, not
> too slow at all. Fwiw, check this out, tell me what you think.

Then the number of mutexes would be fixed.

On 9/7/2023 12:27 PM, Bonita Montero wrote:
> Am 07.09.2023 um 21:06 schrieb Chris M. Thomasson:
>
>> No. A simple hash of a pointer into an index works out okay, not
>> too  slow at all. Fwiw, check this out, tell me what you think.
>
> Then the number of mutexes would be fixed.
>

Yup. It uses address based hashing into the fixed mutex table. It can be
used to simulate atomics when:

https://en.cppreference.com/w/cpp/atomic/atomic/is_lock_free

is false.

On 9/7/23 12:20 PM, Chris M. Thomasson wrote:
> On 9/7/2023 11:06 AM, Richard Damon wrote:
>> On 9/7/23 10:27 AM, Scott Lurndal wrote:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>> Am 07.09.2023 um 16:44 schrieb Pavel:
>>>>
>>>>> How so? Waiters will wait for the time of initialization.
>>>>> The initializing thread will be yielded ...
>>>>
>>>> Initializing is usually much faster than a whole timeslice,
>>>> so yielding would be incacceptabel. That's just a stupid idea.
>>>
>>> So tell us, on which operating systems will there be more than
>>> one thread running when application static objects are
>>> initialized (which happens generally before the application
>>> 'main' function is called, and thus before the application
>>> has a chance to create any threads)?
>>
>> While GLOBAL static objects get initialized before main starts,
>> function local static objects don't get initialized until the first
>> call of the function. These will need some synchronization if the
>> function is called from multiple threads at "the same time".
>
> A simple global hash lock scheme is where we can hash addresses directly
> into a static locking table. The lock table is created _before_ any
> program logic is executed.
>
> https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/wwYQCG2hAwAJ
>
>
>> Also, some global object could start up a thread in its constructor.
>
> YIKES! Shit. I have had to debug other peoples code that did this. Many
> points of errors... One was a rather common peach of a bug. The
> constructor would create a thread that would in turn call into a virtual
> function and start using the object before its constructor was
> completed. A massive race condition, nasty ones!
>

Yes, such a thread needs to understand that the system isn't fully
configured. And yes, a base class creating a thread needs that thread to
understand that the object isn't fully created yet and do something to
handle that issue (which likely requires some help from the most derived
class).

On 9/7/2023 12:52 PM, Richard Damon wrote:
> On 9/7/23 12:20 PM, Chris M. Thomasson wrote:
>> On 9/7/2023 11:06 AM, Richard Damon wrote:
>>> On 9/7/23 10:27 AM, Scott Lurndal wrote:
>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>> Am 07.09.2023 um 16:44 schrieb Pavel:
>>>>>
>>>>>> How so? Waiters will wait for the time of initialization.
>>>>>> The initializing thread will be yielded ...
>>>>>
>>>>> Initializing is usually much faster than a whole timeslice,
>>>>> so yielding would be incacceptabel. That's just a stupid idea.
>>>>
>>>> So tell us, on which operating systems will there be more than
>>>> one thread running when application static objects are
>>>> initialized (which happens generally before the application
>>>> 'main' function is called, and thus before the application
>>>> has a chance to create any threads)?
>>>
>>> While GLOBAL static objects get initialized before main starts,
>>> function local static objects don't get initialized until the first
>>> call of the function. These will need some synchronization if the
>>> function is called from multiple threads at "the same time".
>>
>> A simple global hash lock scheme is where we can hash addresses
>> directly into a static locking table. The lock table is created
>> _before_ any program logic is executed.
>>
>> https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/wwYQCG2hAwAJ
>>
>>
>>> Also, some global object could start up a thread in its constructor.
>>
>> YIKES! Shit. I have had to debug other peoples code that did this.
>> Many points of errors... One was a rather common peach of a bug. The
>> constructor would create a thread that would in turn call into a
>> virtual function and start using the object before its constructor was
>> completed. A massive race condition, nasty ones!
>>
>
> Yes, such a thread needs to understand that the system isn't fully
> configured. And yes, a base class creating a thread needs that thread to
> understand that the object isn't fully created yet and do something to
> handle that issue (which likely requires some help from the most derived
> class).

I actually got to a point where I said no creating threads in
constructors! I have seen to many problems. Create the object _first_,
then expose it to a thread, or create a thread that works with the
_fully_ constructed object. The types of race conditions I have had to
deal with wrt objects creating threads in constructors have tended to be
rather nasty in nature...

Am 07.09.2023 um 21:41 schrieb Chris M. Thomasson:

> Yup. It uses address based hashing into the fixed mutex table.

I guess that's not used at all in the runtimes.

On 9/7/23 12:58 PM, Chris M. Thomasson wrote:
> On 9/7/2023 12:52 PM, Richard Damon wrote:
>> On 9/7/23 12:20 PM, Chris M. Thomasson wrote:
>>> On 9/7/2023 11:06 AM, Richard Damon wrote:
>>>> On 9/7/23 10:27 AM, Scott Lurndal wrote:
>>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>>> Am 07.09.2023 um 16:44 schrieb Pavel:
>>>>>>
>>>>>>> How so? Waiters will wait for the time of initialization.
>>>>>>> The initializing thread will be yielded ...
>>>>>>
>>>>>> Initializing is usually much faster than a whole timeslice,
>>>>>> so yielding would be incacceptabel. That's just a stupid idea.
>>>>>
>>>>> So tell us, on which operating systems will there be more than
>>>>> one thread running when application static objects are
>>>>> initialized (which happens generally before the application
>>>>> 'main' function is called, and thus before the application
>>>>> has a chance to create any threads)?
>>>>
>>>> While GLOBAL static objects get initialized before main starts,
>>>> function local static objects don't get initialized until the first
>>>> call of the function. These will need some synchronization if the
>>>> function is called from multiple threads at "the same time".
>>>
>>> A simple global hash lock scheme is where we can hash addresses
>>> directly into a static locking table. The lock table is created
>>> _before_ any program logic is executed.
>>>
>>> https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/wwYQCG2hAwAJ
>>>
>>>
>>>> Also, some global object could start up a thread in its constructor.
>>>
>>> YIKES! Shit. I have had to debug other peoples code that did this.
>>> Many points of errors... One was a rather common peach of a bug. The
>>> constructor would create a thread that would in turn call into a
>>> virtual function and start using the object before its constructor
>>> was completed. A massive race condition, nasty ones!
>>>
>>
>> Yes, such a thread needs to understand that the system isn't fully
>> configured. And yes, a base class creating a thread needs that thread
>> to understand that the object isn't fully created yet and do something
>> to handle that issue (which likely requires some help from the most
>> derived class).
>
> I actually got to a point where I said no creating threads in
> constructors! I have seen to many problems. Create the object _first_,
> then expose it to a thread, or create a thread that works with the
> _fully_ constructed object. The types of race conditions I have had to
> deal with wrt objects creating threads in constructors have tended to be
> rather nasty in nature...

I have ONE class that does this, but it is for a somewhat specific
embedded environment with deterministic scheduling and just a single
core, so the thread is created with a lower priority then the creator so
it can't start running until the creator blocks, which it isn't allowed
to do until the constructor finishes. It also is normally used early in
the program before the "OS" is turned on, so the created thread can't
actually run until the OS is turned on.

But, for the more general case where you can't control that, (under more
"normal" conditions on the typical "powerful" computer), yes, that would
be a risky thing to be doing.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>On 9/7/2023 12:52 PM, Richard Damon wrote:
>> On 9/7/23 12:20 PM, Chris M. Thomasson wrote:
>>> On 9/7/2023 11:06 AM, Richard Damon wrote:
>>>> On 9/7/23 10:27 AM, Scott Lurndal wrote:
>>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>>> Am 07.09.2023 um 16:44 schrieb Pavel:
>>>>>>
>>>>>>> How so? Waiters will wait for the time of initialization.
>>>>>>> The initializing thread will be yielded ...
>>>>>>
>>>>>> Initializing is usually much faster than a whole timeslice,
>>>>>> so yielding would be incacceptabel. That's just a stupid idea.
>>>>>
>>>>> So tell us, on which operating systems will there be more than
>>>>> one thread running when application static objects are
>>>>> initialized (which happens generally before the application
>>>>> 'main' function is called, and thus before the application
>>>>> has a chance to create any threads)?
>>>>
>>>> While GLOBAL static objects get initialized before main starts,
>>>> function local static objects don't get initialized until the first
>>>> call of the function. These will need some synchronization if the
>>>> function is called from multiple threads at "the same time".
>>>
>>> A simple global hash lock scheme is where we can hash addresses
>>> directly into a static locking table. The lock table is created
>>> _before_ any program logic is executed.
>>>
>>> https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/wwYQCG2hAwAJ
>>>
>>>
>>>> Also, some global object could start up a thread in its constructor.
>>>
>>> YIKES! Shit. I have had to debug other peoples code that did this.
>>> Many points of errors... One was a rather common peach of a bug. The
>>> constructor would create a thread that would in turn call into a
>>> virtual function and start using the object before its constructor was
>>> completed. A massive race condition, nasty ones!
>>>
>>
>> Yes, such a thread needs to understand that the system isn't fully
>> configured. And yes, a base class creating a thread needs that thread to
>> understand that the object isn't fully created yet and do something to
>> handle that issue (which likely requires some help from the most derived
>> class).
>
>I actually got to a point where I said no creating threads in
>constructors! I have seen to many problems. Create the object _first_,
>then expose it to a thread, or create a thread that works with the
>_fully_ constructed object. The types of race conditions I have had to
>deal with wrt objects creating threads in constructors have tended to be
>rather nasty in nature...

The race condition is pretty easy to resolve. Turn thread initialization
into a two-phase operation.

When we have an object that requires its own thread, it will inherit
from a base class called c_thread. The constructor for c_thread will
create the thread which eventually executes the objects 'run' function. The
pthread_create call starts the thread executing at the static function
c_thread::run(void *obj), where the argument is a pointer to the object
itself.

That static function sets the process name (prctl(PR_SET_NAME)) and
then waits on a pthread_cond_t (thread_initialized) declared as a data member of
c_thread.

Meanwhile, the derived object constructor runs in the original thread after the c_thread
constructor returns and initializes the object. Once the object is fully
initialized (which may happen in the constructor, or may happen
at some later point in time during program startup), the c_thread::run
method condition variable (thread_initialized) is signaled and the
static ::run function transfers control to the derived class virtual ::run
function.

/**
* Static pthread start function. Invokes thread specific run virtual
* function.
*
* @param arg The class object pointer passed in from the pthread_create.
*/
void *
c_thread::run(void *arg)
{ c_thread *tp = (c_thread *)arg;
int diag;

pthread_mutex_lock(&tp->t_threadlock);
while (!tp->t_thread_initialized) {
pthread_cond_wait(&tp->t_ready, &tp->t_threadlock);
}
pthread_mutex_unlock(&tp->t_threadlock);

diag = prctl(PR_SET_NAME, tp->t_thread_name, NULL, NULL, NULL, NULL);
if (diag == -1) {
tp->t_logger->log("Unable to set thread name: %s\n", strerror(errno));
}

tp->t_running = true;
tp->run();
tp->t_running = false;

return NULL;
}

Bonita Montero wrote:
> Am 07.09.2023 um 16:44 schrieb Pavel:
>
>> How so? Waiters will wait for the time of initialization.
>> The initializing thread will be yielded ...
>
> Initializing is usually much faster than a whole timeslice,
> so yielding would be incacceptabel. That's just a stupid idea.
Mutex makes thread waiting for initialization not runnable. Yield leaves
it runnable. Therefore, waking up a thread that acquired the mutex is
actually slower than the time needed by thread that yielded to get
running again. This is regardless of whether initializing is slow or fast.

>
>> try_lock in a loop with a sleep or yield wouldn't fail. ...
>
> Do you really think someone would accept spinning with that ?
I don't have to think about this because I know many do.

> This means that an initializing thread which is scheduled away
> while holding the mutex might keep other threads spinning for
> a long time.
No, it can be scheduled away only momentarily because the waiting
threads will relinquish the CPU instantly after being scheduled.

>
>> Regardless, your argument assumes too much C++-morphism in the
>> implementation whereas the implementation can use any platform
>> -specific  approach available to it. E.g. pthread_once on Linux
>> does not fail if given valid arguments ...
>
> pthread_once could be implemented with a single central semaphore
pthread_once takes a statically-initialized pthread_once_t "once
control" that the calling code must supply. It is against the purpose of
pthread_once to wait for a single central semaphore. On the opposite,
the goal is to let the client code control the concurrency by selecting
how many "once control" they want to use.

> for
> all operations and if the implementers know that the synchronization
> itself doesn't fail and the semphore is pre-allocated by the runtime
> it's possible to survive that synchronization without error.
correct. My point exactly.

> But check that code:
>
> #include <iostream>
> #include <thread>
> #include <vector>
>
> using namespace std;
>
> template<unsigned Thread>
> struct SleepAtInitialize
> {
>     SleepAtInitialize()
>     {
>         this_thread::sleep_for( 1s );
>     }
> };
>
> int main()
> {
>     auto unroll = []<size_t ... Indices>( index_sequence<Indices ...>,
> auto fn )
>     {
>         ((fn.template operator ()<Indices>()), ...);
>     };
>     constexpr unsigned N_THREADS = 10;
>     vector<jthread> threads;
>     threads.reserve( N_THREADS );
>     unroll( make_index_sequence<N_THREADS>(),
>         [&]<unsigned Thread>()
>         {
>             threads.emplace_back(
>                 [&]<unsigned IObj>( integral_constant<unsigned, IObj> )
>                 {
>                     static SleepAtInitialize<IObj> guard;
>                 }, integral_constant<unsigned, Thread>() );
>         } );
>
> }
>
> This code runs with individual mutexes per object, i.e. the time
> taken is about one second (with MSVC, libc++ and libstdc++). So
> when individual mutexes are used the initialization may fail.
See above for why pthread_once implementation should also take one
second with the individual pthread_once_t once controls per object.

>
>> Correct, the above was wrong. But initialization can catch and try
>> again. ...
>
> That a bumbler solution.
mutex locking does not fail for no reason. In practice on Linux if the
mutex is in the committed memory and is propertly prioritized and
permissioned and is non-robust (all of which one should assume to be
true for a mutex used by a C++ implementation for initialization) I am
unaware of any reason for why non-timed locking may fail other than
deadlock detection. C++ behavior for the scenario when static
initialization deadlocks is unspecified so the above solution is no
better or worse than any other.