Am 08.09.2023 um 02:53 schrieb Pavel:

> Bonita Montero wrote:

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

However, using sth. like yield is unacceptably slow.

> No, it can be scheduled away only momentarily because the waiting
> threads will relinquish the CPU instantly after being scheduled.

The thread might be scheduled away many timeslices - that's
unacceptable.

> See above for why pthread_once implementation should also take one
> second with the individual pthread_once_t once controls per object.

As you can see from my source the common runtimes use a mutex per
object. This creation may fail.

> mutex locking does not fail for no reason. ...

It's like when a memory allocation would fail and you would
spin until it doesn't fail again. That's also unacceptable.

Am 07.09.23 um 18:39 schrieb Bonita Montero:
> 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.

You do not loose a whole time slice.
This is only true if all available CPU cores are already at 100% load.
In this case you likely loose some time slices anyway.

Normally the spin lock has only the overhead of the additional context
switches. This turns into some short delay if all CPU cores are at full
load, which is of course intended.

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

This is almost impossible since the spinning thread will block the CPU
for only one additional context switch. So the maximum impact is the
number of spinning threads vs. the number of working threads. Assuming
the the working threads likely do not call yield all the time they get
much more resources than this worst case scenario.

Marcel

Bonita Montero wrote:
> Am 08.09.2023 um 02:53 schrieb Pavel:
>
>> Bonita Montero wrote:
>
>>> 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.
>
> However, using sth. like yield is unacceptably slow.
As per the above yield-based waiting for initialization is not slower
than mutex-based. Hence, this "unacceptably slow is nonsense.

>
>> No, it can be scheduled away only momentarily because the waiting
>> threads will relinquish the CPU instantly after being scheduled.
>
> The thread might be scheduled away many timeslices -
A thread that waits for the contended mutex is, upon locking the mutex,
scheduled identically to yield so no difference with mutex

> that's
> unacceptable.
as per the above, this "unacceptale" is nonsense, too.

>
>
>> See above for why pthread_once implementation should also take one
>> second with the individual pthread_once_t once controls per object.
>
> As you can see from my source the common runtimes use a mutex per
> object.
On the opposite, I can see in glibc source code that pthread_once for
linux (which is most common) does not use mutex. There is no "creation",
pthread_once_t is an int.

> This creation may fail.
as per the above, there is nothing to fail unless someone decides to
allocate the int in free memory -- which is not done for static
initialization.

>
>> mutex locking does not fail for no reason. ...
>
> It's like when a memory allocation would fail and you would
> spin until it doesn't fail again.
as per the above, there is nothing to fail unless someone decides to
allocate the int in free memory -- which is not done for static
initialization.

> That's also unacceptable.
as per the above, this "unacceptale" is nonsense, too.

On 9/7/2023 1:31 PM, Richard Damon wrote:
> 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.

Actually, one way that works pretty good, aka not make me freak out,
lol, wrt creating a thread in a constructor is to create a little proxy
object. Something along the lines of:

template<typename T>
struct thread_proxy
{ T m_object;
std::thread m_thread;
};

We can launch the thread in the constructor of thread_proxy<T>

The thread calls a function in T called thread_entry or whatever. This
ensures that T is 100% _fully_ constructed before the thread is created
and starts working with the damn thing. Imvvvho, this is a lot better
than creating the thread directly in T's constructor.

Actually, I need to get back into threads for some rendering work of mine.

On 9/6/2023 7:54 PM, 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 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.
>

Limited spin locking in user space is fine. Think about it for a
moment... Think of adaptive mutex logic... They will try to spin wait a
couple of times on a contended state before using the kernel to actually
wait. No problem with that, right?

On 9/7/2023 1:00 PM, Bonita Montero wrote:
> 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.
>

Why not?

On 9/7/2023 10:37 PM, Bonita Montero wrote:
> Am 08.09.2023 um 02:53 schrieb Pavel:
>
>> Bonita Montero wrote:
>
>>> 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.
>
> However, using sth. like yield is unacceptably slow.

Huh? Think of an adaptive mutex for a moment... :^)

>
>> No, it can be scheduled away only momentarily because the waiting
>> threads will relinquish the CPU instantly after being scheduled.
>
> The thread might be scheduled away many timeslices - that's
> unacceptable.
>
>
>> See above for why pthread_once implementation should also take one
>> second with the individual pthread_once_t once controls per object.
>
> As you can see from my source the common runtimes use a mutex per
> object. This creation may fail.
>
>> mutex locking does not fail for no reason. ...
>
> It's like when a memory allocation would fail and you would
> spin until it doesn't fail again. That's also unacceptable.
>
>

Chris M. Thomasson wrote:
> On 9/7/2023 1:00 PM, Bonita Montero wrote:
>> 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.
>>
>
> Why not?

I think it's not needed in general for static initialization purpose.

This is because, if our design choice for our "C++ compiler" is to use a
dedicated mutex (or once_flag control) per a static variable that
requires dynamic initialization, nothing prevents our compiler from
allocating a static instance of such mutex or control next to the static
variable.

Because mutex and once_flag can be constant-initialized (at least in
POSIX, notably Linux), the code that dynamically initializes a variable
can directly use the address of its respective constant-initialized
mutex or control, as in the following example:

code in C++ source file:

static type1 var1 = InitVar1();

**pseudo-code** actually generated by the compiler:

pthread_once_t __var1_once_control = PTHREAD_ONCE_INIT; /* generated
by the compiler when */

static type1 var1 = InitVar1(); /* this is compiled to,
**in pseudo-code**, to something like

pthread_once( [&var1]() { var1 = InitVar1(); } );
*/

On 9/8/2023 5:14 PM, Pavel wrote:
> Chris M. Thomasson wrote:
>> On 9/7/2023 1:00 PM, Bonita Montero wrote:
>>> 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.
>>>
>>
>> Why not?
>
> I think it's not needed in general for static initialization purpose.
>
> This is because, if our design choice for our "C++ compiler" is to use a
> dedicated mutex (or once_flag control) per a static variable that
> requires dynamic initialization, nothing prevents our compiler from
> allocating a static instance of such mutex or control next to the static
> variable.
>
> Because mutex and once_flag can be constant-initialized (at least in
> POSIX, notably Linux), the code that dynamically initializes a variable
> can directly use the address of its respective constant-initialized
> mutex or control, as in the following example:
>
> code in C++ source file:
>
> static type1 var1 = InitVar1();
>
> **pseudo-code** actually generated by the compiler:
>
> pthread_once_t __var1_once_control = PTHREAD_ONCE_INIT; /* generated
> by the compiler when  */
>
> static type1 var1 = InitVar1(); /* this is compiled to,
> **in pseudo-code**, to something like
>
>  pthread_once( [&var1]() { var1 = InitVar1(); } );
> */

pthread_once is perfectly fine. Just wondering, are you creating the
POSIX impl directly here?

On 9/8/2023 6:05 PM, Chris M. Thomasson wrote:
> On 9/8/2023 5:14 PM, Pavel wrote:
>> Chris M. Thomasson wrote:
>>> On 9/7/2023 1:00 PM, Bonita Montero wrote:
>>>> 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.
>>>>
>>>
>>> Why not?
>>
>> I think it's not needed in general for static initialization purpose.
>>
>> This is because, if our design choice for our "C++ compiler" is to use
>> a dedicated mutex (or once_flag control) per a static variable that
>> requires dynamic initialization, nothing prevents our compiler from
>> allocating a static instance of such mutex or control next to the
>> static variable.
>>
>> Because mutex and once_flag can be constant-initialized (at least in
>> POSIX, notably Linux), the code that dynamically initializes a
>> variable can directly use the address of its respective
>> constant-initialized mutex or control, as in the following example:
>>
>> code in C++ source file:
>>
>> static type1 var1 = InitVar1();
>>
>> **pseudo-code** actually generated by the compiler:
>>
>> pthread_once_t __var1_once_control = PTHREAD_ONCE_INIT; /* generated
>> by the compiler when  */
>>
>> static type1 var1 = InitVar1(); /* this is compiled to,
>> **in pseudo-code**, to something like
>>
>>   pthread_once( [&var1]() { var1 = InitVar1(); } );
>> */
>
> pthread_once is perfectly fine. Just wondering, are you creating the
> POSIX impl directly here?

Think of how you would directly implement pthread_once... There are many
different ways.

On 9/7/2023 2:55 AM, Paavo Helde wrote:
> 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.

If it does fail, then some rather radical shit has hit the fan.

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

Right. The implementation must get it right using fine grain locking,
amortized table locking, or some other means. The compiler and POSIX
worth together like a system. Iirc, I saw another way that was
lock-free, but allowed a thread to create an object, then might have to
delete it because it was not the first one to be installed in the sense
of being visible to other threads. This was decades ago, iirc it used
CAS. No mutex.

On 9/8/2023 6:22 PM, Chris M. Thomasson wrote:
> On 9/7/2023 2:55 AM, Paavo Helde wrote:
>> 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.
>
> If it does fail, then some rather radical shit has hit the fan.
>
>
>>
>> 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.
>
> Right. The implementation must get it right using fine grain locking,
> amortized table locking, or some other means. The compiler and POSIX
> worth together like a system. Iirc, I saw another way that was
> lock-free, but allowed a thread to create an object, then might have to
> delete it because it was not the first one to be installed in the sense
> of being visible to other threads. This was decades ago, iirc it used
> CAS. No mutex.

Iirc it was something like:

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

else
{ // mb acquire
}

l_foo->bar();

Am 08.09.2023 um 22:26 schrieb Chris M. Thomasson:

> Why not?

Because there are simpler ideas that work.

Am 08.09.2023 um 20:54 schrieb Pavel:

> As per the above yield-based waiting for initialization is not slower
> than mutex-based. Hence, this "unacceptably slow is nonsense.

Of course it is slower because you wait N timeslices.

> A thread that waits for the contended mutex is, upon locking the mutex,
> scheduled identically to yield so no difference with mutex

No, a thread waiting for a mutex doesn's spin when the thread holding
the spinlock is scheduled away but it is sleeping inside the kernel.
That's more efficient.

> On the opposite, I can see in glibc source code that pthread_once for
> linux (which is most common) does not use mutex. There is no "creation",
> pthread_once_t is an int.

pthread_once uses a mutex internally for sure.

09.09.2023 06:44 Bonita Montero kirjutas:
>
> pthread_once uses a mutex internally for sure.
>

pthread_once source code can be found by google:
https://elixir.bootlin.com/glibc/latest/source/nptl/pthread_once.c

From there I can see that it calls atomic_load_acquire(). Only if this
fails, will it call __pthread_once_slow() in the slow branch, which uses
futexes. Some other googling reveals that: "a futex ("Fast Userspace
Mutex") isn't a mutex at all"

Am 09.09.2023 um 16:54 schrieb Paavo Helde:

> From there I can see that it calls atomic_load_acquire(). Only if this
> fails, will it call __pthread_once_slow() in the slow branch, which uses
> futexes. Some other googling reveals that: "a futex ("Fast Userspace
> Mutex") isn't a mutex at all"

Doesn't matter since the standard should honor static initialization
that fails because of synchronization woes. And as I've shown with
my code MSVC, libstdc++ and libc++ have a mutex per static initiali-
zation, so pthread_once doesn't apply here.

Bonita Montero wrote:
> Am 09.09.2023 um 16:54 schrieb Paavo Helde:
>
>>  From there I can see that it calls atomic_load_acquire(). Only if
>> this fails, will it call __pthread_once_slow() in the slow branch,
>> which uses futexes. Some other googling reveals that: "a futex ("Fast
>> Userspace Mutex") isn't a mutex at all"
>
> Doesn't matter since the standard should honor static initialization
> that fails because of synchronization woes. And as I've shown with
> my code MSVC, libstdc++ and libc++ have a mutex per static initiali-
> zation, so pthread_once doesn't apply here.

If Microsoft implemented standard wrongly, it's Microsoft's failure, not
the standard's.

Chris M. Thomasson wrote:
> On 9/8/2023 5:14 PM, Pavel wrote:
>> Chris M. Thomasson wrote:
>>> On 9/7/2023 1:00 PM, Bonita Montero wrote:
>>>> 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.
>>>>
>>>
>>> Why not?
>>
>> I think it's not needed in general for static initialization purpose.
>>
>> This is because, if our design choice for our "C++ compiler" is to use
>> a dedicated mutex (or once_flag control) per a static variable that
>> requires dynamic initialization, nothing prevents our compiler from
>> allocating a static instance of such mutex or control next to the
>> static variable.
>>
>> Because mutex and once_flag can be constant-initialized (at least in
>> POSIX, notably Linux), the code that dynamically initializes a
>> variable can directly use the address of its respective
>> constant-initialized mutex or control, as in the following example:
>>
>> code in C++ source file:
>>
>> static type1 var1 = InitVar1();
>>
>> **pseudo-code** actually generated by the compiler:
>>
>> pthread_once_t __var1_once_control = PTHREAD_ONCE_INIT; /* generated
>> by the compiler when  */
>>
>> static type1 var1 = InitVar1(); /* this is compiled to,
>> **in pseudo-code**, to something like
>>
>>   pthread_once( [&var1]() { var1 = InitVar1(); } );
>> */
>
> pthread_once is perfectly fine. Just wondering, are you creating the
> POSIX impl directly here?
I am not creating, just demonstrating in pseudo-code how Linux
implementation could work.

Chris M. Thomasson wrote:
> On 9/8/2023 6:05 PM, Chris M. Thomasson wrote:
>> On 9/8/2023 5:14 PM, Pavel wrote:
>>> Chris M. Thomasson wrote:
>>>> On 9/7/2023 1:00 PM, Bonita Montero wrote:
>>>>> 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.
>>>>>
>>>>
>>>> Why not?
>>>
>>> I think it's not needed in general for static initialization purpose.
>>>
>>> This is because, if our design choice for our "C++ compiler" is to
>>> use a dedicated mutex (or once_flag control) per a static variable
>>> that requires dynamic initialization, nothing prevents our compiler
>>> from allocating a static instance of such mutex or control next to
>>> the static variable.
>>>
>>> Because mutex and once_flag can be constant-initialized (at least in
>>> POSIX, notably Linux), the code that dynamically initializes a
>>> variable can directly use the address of its respective
>>> constant-initialized mutex or control, as in the following example:
>>>
>>> code in C++ source file:
>>>
>>> static type1 var1 = InitVar1();
>>>
>>> **pseudo-code** actually generated by the compiler:
>>>
>>> pthread_once_t __var1_once_control = PTHREAD_ONCE_INIT; /* generated
>>> by the compiler when  */
>>>
>>> static type1 var1 = InitVar1(); /* this is compiled to,
>>> **in pseudo-code**, to something like
>>>
>>>   pthread_once( [&var1]() { var1 = InitVar1(); } );
>>> */
>>
>> pthread_once is perfectly fine. Just wondering, are you creating the
>> POSIX impl directly here?
>
> Think of how you would directly implement pthread_once... There are many
> different ways.
You are correct, there are. Fortunately, I don't have to reinvent this
particular wheel as the implementation source code is available for
everyone to read. On Linux, Futex is a natural choice.

Other platforms can have theirs. I did not program for Windows for long
time but I would at least try to implement call_once with a critical
section (whose creation, contrary to OP's insinuations, cannot fail
since Windows Vista).

On 9/9/2023 11:00 AM, Pavel wrote:
> Chris M. Thomasson wrote:
>> On 9/8/2023 6:05 PM, Chris M. Thomasson wrote:
>>> On 9/8/2023 5:14 PM, Pavel wrote:
>>>> Chris M. Thomasson wrote:
>>>>> On 9/7/2023 1:00 PM, Bonita Montero wrote:
>>>>>> 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.
>>>>>>
>>>>>
>>>>> Why not?
>>>>
>>>> I think it's not needed in general for static initialization purpose.
>>>>
>>>> This is because, if our design choice for our "C++ compiler" is to
>>>> use a dedicated mutex (or once_flag control) per a static variable
>>>> that requires dynamic initialization, nothing prevents our compiler
>>>> from allocating a static instance of such mutex or control next to
>>>> the static variable.
>>>>
>>>> Because mutex and once_flag can be constant-initialized (at least in
>>>> POSIX, notably Linux), the code that dynamically initializes a
>>>> variable can directly use the address of its respective
>>>> constant-initialized mutex or control, as in the following example:
>>>>
>>>> code in C++ source file:
>>>>
>>>> static type1 var1 = InitVar1();
>>>>
>>>> **pseudo-code** actually generated by the compiler:
>>>>
>>>> pthread_once_t __var1_once_control = PTHREAD_ONCE_INIT; /* generated
>>>> by the compiler when  */
>>>>
>>>> static type1 var1 = InitVar1(); /* this is compiled to,
>>>> **in pseudo-code**, to something like
>>>>
>>>>   pthread_once( [&var1]() { var1 = InitVar1(); } );
>>>> */
>>>
>>> pthread_once is perfectly fine. Just wondering, are you creating the
>>> POSIX impl directly here?
>>
>> Think of how you would directly implement pthread_once... There are
>> many different ways.
> You are correct, there are. Fortunately, I don't have to reinvent this
> particular wheel as the implementation source code is available for
> everyone to read. On Linux, Futex is a natural choice.
>
> Other platforms can have theirs. I did not program for Windows for long
> time but I would at least try to implement call_once with a critical
> section (whose creation, contrary to OP's insinuations, cannot fail
> since Windows Vista).

Iirc, Windows has a futex like "thing". I cannot remember the API right
now. Will get back to you.

On 9/8/2023 8:26 PM, Bonita Montero wrote:
> Am 08.09.2023 um 22:26 schrieb Chris M. Thomasson:
>
>> Why not?
>
> Because there are simpler ideas that work.
>

Not exactly sure how to parse that, but sure. As long as it works.

On 9/8/2023 8:44 PM, Bonita Montero wrote:
> Am 08.09.2023 um 20:54 schrieb Pavel:
>
>> As per the above yield-based waiting for initialization is not slower
>> than mutex-based. Hence, this "unacceptably slow is nonsense.
>
> Of course it is slower because you wait N timeslices.
>
>> A thread that waits for the contended mutex is, upon locking the
>> mutex, scheduled identically to yield so no difference with mutex
>
> No, a thread waiting for a mutex doesn's spin when the thread holding
> the spinlock is scheduled away but it is sleeping inside the kernel.
> That's more efficient.

So, you must really dislike adaptive mutex designs, right? If so, why?
They can spin several times before waiting in the kernel... Really slow
path, so to speak. Btw, do you think that adaptive mutex are really bad?
If so, why?

>
>> On the opposite, I can see in glibc source code that pthread_once for
>> linux (which is most common) does not use mutex. There is no
>> "creation", pthread_once_t is an int.
>
> pthread_once uses a mutex internally for sure.
>
>

On 9/9/2023 10:26 AM, Bonita Montero wrote:
> Am 09.09.2023 um 16:54 schrieb Paavo Helde:
>
>>  From there I can see that it calls atomic_load_acquire(). Only if
>> this fails, will it call __pthread_once_slow() in the slow branch,
>> which uses futexes. Some other googling reveals that: "a futex ("Fast
>> Userspace Mutex") isn't a mutex at all"
>
> Doesn't matter since the standard should honor static initialization
> that fails because of synchronization woes. And as I've shown with
> my code MSVC, libstdc++ and libc++ have a mutex per static initiali-
> zation, so pthread_once doesn't apply here.

Huh? pthread_once totally applies here. Windows has futex like abilities.

Am 09.09.2023 um 19:42 schrieb Pavel:

> If Microsoft implemented standard wrongly, it's Microsoft's failure, not
> the standard's.

The standard doesn't say anything to the issue I've shown.

Am 09.09.2023 um 20:49 schrieb Chris M. Thomasson:

> Huh? pthread_once totally applies here. Windows has futex like abilities.

It doesn't matter what Posix or Win32 says. The standard should
honour that static initialization might fail because of creating
a synchronization primitive or synchronizing on them. The standard
shoudln't require that this never fails.