Am 19.09.2023 um 21:30 schrieb Chris M. Thomasson:

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

I've read the paper, you didn't.

Am 20.09.2023 um 00:45 schrieb Richard Damon:

> And there are things that work enough like a Mutex to do this, that
> aren't Mutexes ...

Tell me which things you're thinking about. The standard requires that
contenders while static initialization sleep, that is possible ony with
a mutex.

Am 19.09.2023 um 21:12 schrieb Chris M. Thomasson:

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

Idiot.

Am 19.09.2023 um 21:17 schrieb Chris M. Thomasson:

> A locking order is very important ...

There are no deadlocks with locking static initialization.

Am 19.09.2023 um 23:08 schrieb Kaz Kylheku:

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

Static initialization woudln't lock for trivial types.

Am 20.09.2023 um 00:42 schrieb Richard Damon:

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

That's what I said.

On 9/19/2023 8:33 PM, Bonita Montero wrote:
> Am 19.09.2023 um 21:30 schrieb Chris M. Thomasson:
>
>> 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...
>
> I've read the paper, you didn't.
>

Yawn.

On 9/19/2023 8:38 PM, Bonita Montero wrote:
> Am 20.09.2023 um 00:42 schrieb Richard Damon:
>
>> Nope, all that shows is the system can't JUST use one global Mutex.
>
> That's what I said.
>
>

So?

On 2023-09-20, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 19.09.2023 um 23:08 schrieb Kaz Kylheku:
>
>> 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;
>> }
>
> Static initialization woudln't lock for trivial types.

Why would you snip away an actual transcript showing that something is
happening, and claim it woudln't happen?

It has to lock.

If two threads execute this at around the same time:

static int a = B();

one of them has to be delayed until the other finishes
executing B(), initializes a, sets some flag indicating
that this was done, and releases the lock.

The type of a is trivial, but B() isn't trivial; B()
can be an arbitrarily complex calculation, and a is not
initialized until that calculation completes.

Here is part of the transcript again: the gdb backtrace:

(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 ()

The __cxa_guard_acquire that's making a __kernel_vsyscall is
the locking mechanism guarding the "static int a = B()".

It has recursively deadlocked. The main thread already owns
that lock and when it tries to acquire it again, it hangs.

--
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/2023 8:35 PM, Bonita Montero wrote:
> Am 20.09.2023 um 00:45 schrieb Richard Damon:
>
>> And there are things that work enough like a Mutex to do this, that
>> aren't Mutexes ...
>
> Tell me which things you're thinking about. The standard requires that
> contenders while static initialization sleep, that is possible ony with
> a mutex.
>
>

HUH? Barf...

On 9/19/2023 8:35 PM, Bonita Montero wrote:
> Am 19.09.2023 um 21:12 schrieb Chris M. Thomasson:
>
>> Futex has all the kernel resources created up front, Bonita. Also,
>> there  was this interesting method I learned about many years ago:
>
> Idiot.
>
>

Yawn.

On 9/19/2023 8:52 PM, Kaz Kylheku wrote:
> On 2023-09-20, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 19.09.2023 um 23:08 schrieb Kaz Kylheku:
>>
>>> 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;
>>> }
>>
>> Static initialization woudln't lock for trivial types.
>
> Why would you snip away an actual transcript showing that something is
> happening, and claim it woudln't happen?

Bonita is having some sort of a meltdown? Humm...

>
> It has to lock.
>
> If two threads execute this at around the same time:
>
> static int a = B();
>
> one of them has to be delayed until the other finishes
> executing B(), initializes a, sets some flag indicating
> that this was done, and releases the lock.
>
> The type of a is trivial, but B() isn't trivial; B()
> can be an arbitrarily complex calculation, and a is not
> initialized until that calculation completes.
>
> Here is part of the transcript again: the gdb backtrace:
>
> (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 ()
>
> The __cxa_guard_acquire that's making a __kernel_vsyscall is
> the locking mechanism guarding the "static int a = B()".
>
> It has recursively deadlocked. The main thread already owns
> that lock and when it tries to acquire it again, it hangs.
>

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.

Basically, right on.

On Sunday, September 10, 2023 at 7:09:11 PM UTC+3, Paavo Helde wrote:
> 10.09.2023 18:46 Bonita Montero kirjutas:
> > Am 10.09.2023 um 15:51 schrieb Richard Damon:
> >
> >> You don't seem to understand that sincd it CAN be done in a way that
> >> always works, ...
> >
> > A standard shouldn't mandate that this never fails.
> So suppose the standard committee agrees with you and adds a sentence to
> the standard:
>
> Dynamic initialization of a non-local variable with static storage
> duration can fail even if its initializing function does not throw, in
> which case the behavior is ...undefined... / ..unspecified... /
> ...calling std::terminate() after unspecified time...
>
> Which variant do you prefer? And how would this help the programmer who
> needs to write programs in C++? Should they just avoid creating any
> static variables at all, in order to not trigger this failure scenario?

Avoidance of creation of function-scope static variables with non-trivial
constructors is a good guiding principle. Especially so in multithreaded
environment.
Of course, it is a good guiding principle for more important reasons than
one mentioned here.

On 9/19/23 11:38 PM, Bonita Montero wrote:
> Am 20.09.2023 um 00:42 schrieb Richard Damon:
>
>> Nope, all that shows is the system can't JUST use one global Mutex.
>
> That's what I said.
>
>

No, you said it uses an actual full mutex per object.

That actual answer was reported that it uses a single global Mutex to
implement a simple locking primitive (which has a copy per object). The
global mutex is acquired at the very start, and is held only during the
updating of the simple locking primitive, not for the duration that
primitive is held.

But, since you don't understand that, you ignore that such a method is a
possibility.

On 9/19/23 11:35 PM, Bonita Montero wrote:
> Am 20.09.2023 um 00:45 schrieb Richard Damon:
>
>> And there are things that work enough like a Mutex to do this, that
>> aren't Mutexes ...
>
> Tell me which things you're thinking about. The standard requires that
> contenders while static initialization sleep, that is possible ony with
> a mutex.
>
>

Nope, shows your lack of imagination.

I can make a thread wait before going past the initialization point
(which is what is required, not to "Sleep") without using a Mutex.

Am 20.09.2023 um 13:54 schrieb Richard Damon:

> Nope, shows your lack of imagination.

Show me how sleeping works in situation without waiting for a semaphore
which is part of the slow path of a mutex.

Michael S <already5chosen@yahoo.com> writes:
>On Sunday, September 10, 2023 at 7:09:11=E2=80=AFPM UTC+3, Paavo Helde wrot=
>e:
>> 10.09.2023 18:46 Bonita Montero kirjutas:=20
>> > Am 10.09.2023 um 15:51 schrieb Richard Damon:=20
>> >=20
>> >> You don't seem to understand that sincd it CAN be done in a way that=
>=20
>> >> always works, ...=20
>> >=20
>> > A standard shouldn't mandate that this never fails.
>> So suppose the standard committee agrees with you and adds a sentence to=
>=20
>> the standard:=20
>>=20
>> Dynamic initialization of a non-local variable with static storage=20
>> duration can fail even if its initializing function does not throw, in=20
>> which case the behavior is ...undefined... / ..unspecified... /=20
>> ...calling std::terminate() after unspecified time...=20
>>=20
>> Which variant do you prefer? And how would this help the programmer who=
>=20
>> needs to write programs in C++? Should they just avoid creating any=20
>> static variables at all, in order to not trigger this failure scenario?
>
>Avoidance of creation of function-scope static variables with non-trivial
>constructors is a good guiding principle. Especially so in multithreaded
>environment.
>Of course, it is a good guiding principle for more important reasons than
>one mentioned here.

Finally. That's indeed the case.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 20.09.2023 um 13:54 schrieb Richard Damon:
>
>> Nope, shows your lack of imagination.
>
>Show me how sleeping works in situation without waiting for a semaphore
>which is part of the slow path of a mutex.

Does the term 'spin lock' have any meaning to you?

Am 20.09.2023 um 16:20 schrieb Scott Lurndal:

> Does the term 'spin lock' have any meaning to you?

Spinlocks don't work in userspace since a thread holding a spinlock
can be scheduled away, thereby keepin others spinning a long time.
Because of that no one uses pure spinlocks, but just mutexes with
limited spinning and a slow path.

On Wednesday, September 20, 2023 at 4:18:42 PM UTC+3, Bonita Montero wrote:
> Am 20.09.2023 um 13:54 schrieb Richard Damon:
>
> > Nope, shows your lack of imagination.
> Show me how sleeping works in situation without waiting for a semaphore
> which is part of the slow path of a mutex.

That's approximately what I'd do using old (pre-Vista) Win32 API.
With newer APIs I can probably do better.

static CRITICAL_SECTION st_flagUpdatesCs;
static HANDLE st_initWaitEv;

void guarda_init_before_main()
{ InitializeCriticalSection(&st_flagUpdatesCs);
st_initWaitEv = CreateEvent(NULL, TRUE, FALSE, NULL); // Manual Reset
}

int guard_acquire(volatile char* per_object)
{ int ret = 0; // tell to caller that initialization completed
if (*per_object != 1) {
EnterCriticalSection(&st_flagUpdatesCs);
if (*per_object != 1) {
// For sake of brevity let's ignore guarding/abortion
// against recursive initialization of the same object by the same thread
// According to C++ standard it's UB, anyway
while (*per_object & 2) { // init in progress
*per_object |= 4; // announce wait
LeaveCriticalSection(&st_flagUpdatesCs);
WaitForSingleObject(st_initWaitEv, INFINITE);
EnterCriticalSection(&st_flagUpdatesCs);
}
if (*per_object != 1) {
*per_object |= 2; // set init in progress
ret = 1; // tell to caller to perform initialization
}
}
LeaveCriticalSection(&st_flagUpdatesCs);
}
return ret;
}

void guard_release(volatile char* per_object)
{ EnterCriticalSection(&st_flagUpdatesCs);
char val = *per_object;
*per_object = 1; // mark object as initialized
LeaveCriticalSection(&st_flagUpdatesCs);

if (val & 4) // there are waiting threads
PulseEvent(st_initWaitEv); // wake them up
}

On 9/20/2023 1:14 AM, Michael S wrote:
> On Sunday, September 10, 2023 at 7:09:11 PM UTC+3, Paavo Helde wrote:
>> 10.09.2023 18:46 Bonita Montero kirjutas:
>>> Am 10.09.2023 um 15:51 schrieb Richard Damon:
>>>
>>>> You don't seem to understand that sincd it CAN be done in a way that
>>>> always works, ...
>>>
>>> A standard shouldn't mandate that this never fails.
>> So suppose the standard committee agrees with you and adds a sentence to
>> the standard:
>>
>> Dynamic initialization of a non-local variable with static storage
>> duration can fail even if its initializing function does not throw, in
>> which case the behavior is ...undefined... / ..unspecified... /
>> ...calling std::terminate() after unspecified time...
>>
>> Which variant do you prefer? And how would this help the programmer who
>> needs to write programs in C++? Should they just avoid creating any
>> static variables at all, in order to not trigger this failure scenario?
>
> Avoidance of creation of function-scope static variables with non-trivial
> constructors is a good guiding principle. Especially so in multithreaded
> environment.
> Of course, it is a good guiding principle for more important reasons than
> one mentioned here.

You got it!!!

On 9/20/2023 7:31 AM, Bonita Montero wrote:
> Am 20.09.2023 um 16:20 schrieb Scott Lurndal:
>
>> Does the term 'spin lock' have any meaning to you?
>
> Spinlocks don't work in userspace since a thread holding a spinlock
> can be scheduled away, thereby keepin others spinning a long time.
> Because of that no one uses pure spinlocks, but just mutexes with
> limited spinning and a slow path.
>

So, do actually do have a deep hatred of adaptive mutexes, right?

On 9/20/2023 9:48 AM, Michael S wrote:
> On Wednesday, September 20, 2023 at 4:18:42 PM UTC+3, Bonita Montero wrote:
>> Am 20.09.2023 um 13:54 schrieb Richard Damon:
>>
>>> Nope, shows your lack of imagination.
>> Show me how sleeping works in situation without waiting for a semaphore
>> which is part of the slow path of a mutex.
>
> That's approximately what I'd do using old (pre-Vista) Win32 API.
> With newer APIs I can probably do better.
>
> static CRITICAL_SECTION st_flagUpdatesCs;
> static HANDLE st_initWaitEv;
>
> void guarda_init_before_main()
> {
> InitializeCriticalSection(&st_flagUpdatesCs);
> st_initWaitEv = CreateEvent(NULL, TRUE, FALSE, NULL); // Manual Reset
> }
>
> int guard_acquire(volatile char* per_object)
> {
> int ret = 0; // tell to caller that initialization completed
> if (*per_object != 1) {
> EnterCriticalSection(&st_flagUpdatesCs);
> if (*per_object != 1) {
> // For sake of brevity let's ignore guarding/abortion
> // against recursive initialization of the same object by the same thread
> // According to C++ standard it's UB, anyway
> while (*per_object & 2) { // init in progress
> *per_object |= 4; // announce wait
> LeaveCriticalSection(&st_flagUpdatesCs);
> WaitForSingleObject(st_initWaitEv, INFINITE);
> EnterCriticalSection(&st_flagUpdatesCs);
> }
> if (*per_object != 1) {
> *per_object |= 2; // set init in progress
> ret = 1; // tell to caller to perform initialization
> }
> }
> LeaveCriticalSection(&st_flagUpdatesCs);
> }
> return ret;
> }
>
> void guard_release(volatile char* per_object)
> {
> EnterCriticalSection(&st_flagUpdatesCs);
> char val = *per_object;
> *per_object = 1; // mark object as initialized
> LeaveCriticalSection(&st_flagUpdatesCs);
>
> if (val & 4) // there are waiting threads
> PulseEvent(st_initWaitEv); // wake them up

^^^^^^^^^^^^^^^^^

PulseEvent has issues.... Take special note of:

https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-pulseevent
__________
Note This function is unreliable and should not be used. It exists
mainly for backward compatibility. For more information, see Remarks.
__________

So, well, shit.

> }

On Wednesday, September 20, 2023 at 9:55:09 PM UTC+3, Chris M. Thomasson wrote:
> On 9/20/2023 9:48 AM, Michael S wrote:
> > On Wednesday, September 20, 2023 at 4:18:42 PM UTC+3, Bonita Montero wrote:
> >> Am 20.09.2023 um 13:54 schrieb Richard Damon:
> >>
> >>> Nope, shows your lack of imagination.
> >> Show me how sleeping works in situation without waiting for a semaphore
> >> which is part of the slow path of a mutex.
> >
> > That's approximately what I'd do using old (pre-Vista) Win32 API.
> > With newer APIs I can probably do better.
> >
> > static CRITICAL_SECTION st_flagUpdatesCs;
> > static HANDLE st_initWaitEv;
> >
> > void guarda_init_before_main()
> > {
> > InitializeCriticalSection(&st_flagUpdatesCs);
> > st_initWaitEv = CreateEvent(NULL, TRUE, FALSE, NULL); // Manual Reset
> > }
> >
> > int guard_acquire(volatile char* per_object)
> > {
> > int ret = 0; // tell to caller that initialization completed
> > if (*per_object != 1) {
> > EnterCriticalSection(&st_flagUpdatesCs);
> > if (*per_object != 1) {
> > // For sake of brevity let's ignore guarding/abortion
> > // against recursive initialization of the same object by the same thread
> > // According to C++ standard it's UB, anyway
> > while (*per_object & 2) { // init in progress
> > *per_object |= 4; // announce wait
> > LeaveCriticalSection(&st_flagUpdatesCs);
> > WaitForSingleObject(st_initWaitEv, INFINITE);
> > EnterCriticalSection(&st_flagUpdatesCs);
> > }
> > if (*per_object != 1) {
> > *per_object |= 2; // set init in progress
> > ret = 1; // tell to caller to perform initialization
> > }
> > }
> > LeaveCriticalSection(&st_flagUpdatesCs);
> > }
> > return ret;
> > }
> >
> > void guard_release(volatile char* per_object)
> > {
> > EnterCriticalSection(&st_flagUpdatesCs);
> > char val = *per_object;
> > *per_object = 1; // mark object as initialized
> > LeaveCriticalSection(&st_flagUpdatesCs);
> >
> > if (val & 4) // there are waiting threads
> > PulseEvent(st_initWaitEv); // wake them up
> ^^^^^^^^^^^^^^^^^
>
> PulseEvent has issues.... Take special note of:
>
> https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-pulseevent
> __________
> Note This function is unreliable and should not be used. It exists
> mainly for backward compatibility. For more information, see Remarks.
> __________
>
> So, well, shit.
>
> > }

It's unlikely to be unreliable in this particular circumstances.
But apart from it, my code has bug (race condition) :(
Just shows that this sort of crap is not easy.

The simple, if inelegant, fix is to replace
WaitForSingleObject(st_initWaitEv, INFINITE);
with
WaitForSingleObject(st_initWaitEv, 100);

More theoretically sound, but practically bad fix would be to
replace critical section with mutex. Like that:

static HANDLE st_flagUpdatesMtx;
static HANDLE st_initWaitEv;

void guarda_init_before_main()
{ st_flagUpdatesMtx = CreateMutex(NULL, FALSE, NULL);
st_initWaitEv = CreateEvent(NULL, TRUE, FALSE, NULL); // Manual Reset
}

int guard_acquire(volatile char* per_object)
{ int ret = 0; // tell to caller that initialization completed
if (*per_object != 1) {
WaitForSingleObject(st_flagUpdatesMtx, INFINITE); // Enter guarded section
if (*per_object != 1) {
// For sake of brevity let's ignore guarding/abortion
// against recursive initialization of the same object by the same thread
// According to C++ standard it's UB, anyway
while (*per_object & 2) { // init in progress
*per_object |= 4; // announce wait

// combine ReleaseMutex(st_flagUpdatesMtx);
// and WaitForSingleObject(st_initWaitEv, INFINITE);
// in a single call thus avoiding race condition with guard_release()
SignalObjectAndWait(st_flagUpdatesMtx, st_initWaitEv, INFINITE, FALSE);

WaitForSingleObject(st_flagUpdatesMtx, INFINITE); // re-enter guarded section
}
if (*per_object != 1) {
*per_object |= 2; // set init in progress
ret = 1; // tell to caller to perform initialization
}
}
ReleaseMutex(st_flagUpdatesMtx); // Leave guarded section
}
return ret;
}

void guard_release(volatile char* per_object)
{ WaitForSingleObject(st_flagUpdatesMtx, INFINITE); // Enter guarded section
char val = *per_object;
*per_object = 1; // mark object as initialized
ReleaseMutex(st_flagUpdatesMtx); // Leave guarded section

if (val & 4) // there are waiting threads
PulseEvent(st_initWaitEv); // wake them up
}

In practice it is bad solution, because unlike in the first variant, here
we need system calls even in the most common un-contended case.

Naturally, for Vista and later it's all much easier.