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

A recursive lock would be interesting here...

On Wednesday, September 20, 2023 at 10:36:18 PM UTC+3, Michael S wrote:
> 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.

Here is something that looks like better solution for pre-Vista Windows.
Both more robust and more performant than my previous attempts.
More performant in a sense that waiting threads are not awoken spuriously.

void guarda_init_before_main()
{ InitializeCriticalSection(&st_flagUpdatesCs);
}

static void doNothing(ULONG_PTR) {}

static void WakeUpWaitingThread(DWORD threadId)
{ HANDLE hThread = OpenThread(THREAD_SET_CONTEXT, FALSE, threadId);
QueueUserAPC(doNothing, hThread, 0);
CloseHandle(hThread);
}

int guard_acquire(volatile per_object_guard_t* pGuard)
{ if (pGuard->done)
return 0; // tell to caller that initialization completed

EnterCriticalSection(&st_flagUpdatesCs);
if (pGuard->done) {
LeaveCriticalSection(&st_flagUpdatesCs);
return 0; // tell to caller that initialization completed
}

// 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
if (!pGuard->inProgress) {
pGuard->inProgress = true;
pGuard->waitingThreadId = 0; // for illustration, not necessary
LeaveCriticalSection(&st_flagUpdatesCs);
return 1; // tell to caller to perform initialization
}
// init in progress

// insert current tread ID as the first in chain of waiting threads
DWORD previousWaitingThreadId = pGuard->waitingThreadId;
pGuard->waitingThreadId = GetCurrentThreadId();
// Wait for completion of the initialization
// most likely loop is not necessary. But it does no harm
do {
LeaveCriticalSection(&st_flagUpdatesCs);
SleepEx(INFINITE, TRUE);
EnterCriticalSection(&st_flagUpdatesCs);
} while (!pGuard->done);

// init completed by other thread
LeaveCriticalSection(&st_flagUpdatesCs);

if (previousWaitingThreadId != 0)
WakeUpWaitingThread(previousWaitingThreadId); // wake up next waiting thread in chain

return 0; // tell to caller that initialization completed
}

void guard_release(volatile per_object_guard_t* pGuard)
{ EnterCriticalSection(&st_flagUpdatesCs);
DWORD waitingThreadId = pGuard->waitingThreadId;
pGuard->done = true; // mark object as initialized
LeaveCriticalSection(&st_flagUpdatesCs);

if (waitingThreadId != 0)
WakeUpWaitingThread(waitingThreadId); // wake up first waiting thread in chain
}

But it's a night here, so bugs are very possible.

On 2023-09-20, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 9/19/2023 8:52 PM, Kaz Kylheku wrote:
>> It has recursively deadlocked. The main thread already owns
>> that lock and when it tries to acquire it again, it hangs.
>>
>
> A recursive lock would be interesting here...

It wouldn't help; it might "aid and abet" the runaway recursion.

A tri-state flag could detect that case. The tri-state flag initially
shows "uninitialized", and is set into "in progress" during the
initialization and then into the "initialized" state. If it is found in
the "in progress" state, it aborts or throws or whatever, since bad
recursion has been detected.

That would not detect situations of mutual deadlock, like when we
unleash two threads to call A and B. That situation could be
caught by a deadlock-detecting mutex.

Since that would catch the first situation also, there is no need
for that tri-state flag.

--
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/20/2023 2:09 PM, Kaz Kylheku wrote:
> On 2023-09-20, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 9/19/2023 8:52 PM, Kaz Kylheku wrote:
>>> It has recursively deadlocked. The main thread already owns
>>> that lock and when it tries to acquire it again, it hangs.
>>>
>>
>> A recursive lock would be interesting here...
>
> It wouldn't help; it might "aid and abet" the runaway recursion.

Right. I do not like to use them, and this would be an interesting way
to get a "false" sense of "security" for some people. I have had to deal
with nightmare scenarios wrt recursive locking.

> A tri-state flag could detect that case. The tri-state flag initially
> shows "uninitialized", and is set into "in progress" during the
> initialization and then into the "initialized" state. If it is found in
> the "in progress" state, it aborts or throws or whatever, since bad
> recursion has been detected.

>
> That would not detect situations of mutual deadlock, like when we
> unleash two threads to call A and B. That situation could be
> caught by a deadlock-detecting mutex.
>
> Since that would catch the first situation also, there is no need
> for that tri-state flag.
>

I think so. Need to think on it. Runaway recursion is bad for the
program. To detect it we could throw this threads stack is about to
explode error. ;^)

The mutex says I am being locked by the same thread again... Recursion
sucks, so I will throw.

On 2023-09-20, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> 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?

I might have possibly invented those. At least, I wasn't aware of prior
art when I wrote the patch for Glibc.

The reconstructed git history is screwy: the linuxthreads/ChangeLog diff is
in this commit:

https://sourceware.org/git/?p=glibc.git;a=commit;h=a88b96f496c0214424db1219d21ce669fbc102a0

The actual change it refers to is in another commit:

https://sourceware.org/git/?p=glibc.git;a=commit;h=4ad1d0cfbf96c3dbcf0ba104eb9f81bae6bdc6da

--
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/20/23 9:18 AM, 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.
>

What make you think it needs to "sleep". It likely just needs to "Yield"
(like call SwitchToThread) to let other threads get a chance to run, and
then check the initialization status again.

You could also get a bit fancier and build a linked list of waiting
threads that suspend themselfs, and have the initializing thread check
if anyone is waiting and resume them.

You are just showing your lack of imagination.

Bonita Montero wrote:
> Am 19.09.2023 um 02:15 schrieb Pavel:
>
>> Or, when there is nothing to create, there is nothing to defer,
>
> I've shown that static initialization actually uses a mutex per object.
You did not even show that they use mutex at all (which they don't as it
turned out on either Windows or Linux)

> The runtimes for sure not pre-create a number of mutexes for that since
As per above, they don't have to be mutices and in fact are not mutices
on widely prevalent systems so this is irrelevant. More to the point, as
an example, Linux runtime creates a static pthread_once_t per static
variable.

> static objects are just zeroed memory before initialization.
This is irrelevant to the discussion, but still is wrong:

static objects that can be constant-initialized at all can be
initialized to any integral (at least) constant value or structure
thereof. They are only set to zero if they are not initialized
explicitly. Then the memory values are set up at program load time, i.e.
before runtime. This said, the initial value for pthread_once_t control
is chosen to be 0 on my system:

pthread_once_t once_control = PTHREAD_ONCE_INIT;

where

#define PTHREAD_ONCE_INIT 0

but it could be constant-initialized to anything else, e.g. to -1 if the
authors thought it were necessary.

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

Then there are lots of these on prevalent platforms that either cannot
fail at all on either lock if initialized propoerty or on initialization
; or those that cannot fail if initialized in a certain way,
including some type of mutexes. All of these are perfectly suitable for
use in static initialization to make it thread-safe. Hence, no need to
change the standard.

On 9/20/2023 3:23 PM, Kaz Kylheku wrote:
> On 2023-09-20, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> 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?
>
> I might have possibly invented those. At least, I wasn't aware of prior
> art when I wrote the patch for Glibc.
>
> The reconstructed git history is screwy: the linuxthreads/ChangeLog diff is
> in this commit:
>
> https://sourceware.org/git/?p=glibc.git;a=commit;h=a88b96f496c0214424db1219d21ce669fbc102a0
>
> The actual change it refers to is in another commit:
>
> https://sourceware.org/git/?p=glibc.git;a=commit;h=4ad1d0cfbf96c3dbcf0ba104eb9f81bae6bdc6da
>

Nice! NPTL by Ulrich Drepper definitely rings a bell for me. Btw, have
you messed around with distributed mutexes before? I remember reading
about one a while back called the, iirc, M lock. I did an implementation
and posted it over on comp.arch, that thread might be hard to find.
Basically each thread contends on its local state. I wonder if that
paper is still around.

On 9/20/2023 6:46 PM, Chris M. Thomasson wrote:
> On 9/20/2023 3:23 PM, Kaz Kylheku wrote:
>> On 2023-09-20, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> 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?
>>
>> I might have possibly invented those. At least, I wasn't aware of prior
>> art when I wrote the patch for Glibc.
>>
>> The reconstructed git history is screwy: the linuxthreads/ChangeLog
>> diff is
>> in this commit:
>>
>> https://sourceware.org/git/?p=glibc.git;a=commit;h=a88b96f496c0214424db1219d21ce669fbc102a0
>>
>> The actual change it refers to is in another commit:
>>
>> https://sourceware.org/git/?p=glibc.git;a=commit;h=4ad1d0cfbf96c3dbcf0ba104eb9f81bae6bdc6da
>>
>
> Nice! NPTL by Ulrich Drepper definitely rings a bell for me. Btw, have
> you messed around with distributed mutexes before? I remember reading
> about one a while back called the, iirc, M lock. I did an implementation
> and posted it over on comp.arch, that thread might be hard to find.
> Basically each thread contends on its local state. I wonder if that
> paper is still around.

Have not found it yet, but I did find this old post of mine fro 2005:

https://groups.google.com/g/comp.arch/c/shshLdF1uqs

About Sun's KCSS, k compare single swap.

On 9/20/2023 6:46 PM, Chris M. Thomasson wrote:
> On 9/20/2023 3:23 PM, Kaz Kylheku wrote:
>> On 2023-09-20, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> 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?
>>
>> I might have possibly invented those. At least, I wasn't aware of prior
>> art when I wrote the patch for Glibc.
>>
>> The reconstructed git history is screwy: the linuxthreads/ChangeLog
>> diff is
>> in this commit:
>>
>> https://sourceware.org/git/?p=glibc.git;a=commit;h=a88b96f496c0214424db1219d21ce669fbc102a0
>>
>> The actual change it refers to is in another commit:
>>
>> https://sourceware.org/git/?p=glibc.git;a=commit;h=4ad1d0cfbf96c3dbcf0ba104eb9f81bae6bdc6da
>>
>
> Nice! NPTL by Ulrich Drepper definitely rings a bell for me. Btw, have
> you messed around with distributed mutexes before? I remember reading
> about one a while back called the, iirc, M lock. I did an implementation
> and posted it over on comp.arch, that thread might be hard to find.
> Basically each thread contends on its local state. I wonder if that
> paper is still around.

I found it! YEAH!!!

https://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=251B3F934CAB552200421D0570D2D2A1?doi=10.1.1.48.6490&rep=rep1&type=pdf

On 9/20/2023 6:46 PM, Chris M. Thomasson wrote:
> On 9/20/2023 3:23 PM, Kaz Kylheku wrote:
>> On 2023-09-20, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> 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?
>>
>> I might have possibly invented those. At least, I wasn't aware of prior
>> art when I wrote the patch for Glibc.
>>
>> The reconstructed git history is screwy: the linuxthreads/ChangeLog
>> diff is
>> in this commit:
>>
>> https://sourceware.org/git/?p=glibc.git;a=commit;h=a88b96f496c0214424db1219d21ce669fbc102a0
>>
>> The actual change it refers to is in another commit:
>>
>> https://sourceware.org/git/?p=glibc.git;a=commit;h=4ad1d0cfbf96c3dbcf0ba104eb9f81bae6bdc6da
>>
>
> Nice! NPTL by Ulrich Drepper definitely rings a bell for me. Btw, have
> you messed around with distributed mutexes before? I remember reading
> about one a while back called the, iirc, M lock. I did an implementation
> and posted it over on comp.arch, that thread might be hard to find.
> Basically each thread contends on its local state. I wonder if that
> paper is still around.
Finally found it.

http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=251B3F934CAB552200421D0570D2D2A1?doi=10.1.1.48.6490&rep=rep1&type=pdf

Am 20.09.2023 um 18:48 schrieb Michael S:

> On Wednesday, September 20, 2023 at 4:18:42 PM UTC+3, Bonita Montero wrote:

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

CRITICAL sections include an event which in turn is a binary semaphore.
And the naked event itself is also a semaphore.

Am 21.09.2023 um 00:46 schrieb Richard Damon:

> It likely just needs to "Yield"
> (like call SwitchToThread) to let other threads get a chance to run, and
> then check the initialization status again.

A yield yould be to inefficient.

Am 20.09.2023 um 21:36 schrieb Chris M. Thomasson:

> A recursive lock would be interesting here...

A recursive lock is impossible here since the object might have
been partitially initialized and when coming back this partitial
initialization would happen again.

On 9/20/2023 12:36 PM, Michael S wrote:
> 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.

PulseEvent never worked right. Many years ago, I have seem my fair share
of completely broken windows condition variable "things", a lot of them,
sigh... Horrible code, infested with race-conditions that might lead to
deadlock or the nasty lost wake problem. PulseEvent is no good, avoid it
like the damn plague.

On 9/20/2023 12:36 PM, Michael S wrote:
> 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:
[...]
> 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.
[...]
Implement your algorithm in Relacy Race Detector. It can help. I know
the guy who created it. A good guy.

On 9/20/2023 8:42 PM, Bonita Montero wrote:
> Am 21.09.2023 um 00:46 schrieb Richard Damon:
>
>> It likely just needs to "Yield" (like call SwitchToThread) to let
>> other threads get a chance to run, and then check the initialization
>> status again.
>
> A yield yould be to inefficient.

Have you heard about an adaptive backoff, different than a "traditional"
adaptive mutex? It uses several different ways to avoid the kernel. They
are interesting to me.

On 9/20/2023 8:46 PM, Bonita Montero wrote:
> Am 20.09.2023 um 21:36 schrieb Chris M. Thomasson:
>
>> A recursive lock would be interesting here...
>
> A recursive lock is impossible here since the object might have
> been partitially initialized and when coming back this partitial
> initialization would happen again.
>

A recursive would only provide a, so of, false sense of security wrt the
infinite recursion that is present in the user code.

On 2023-09-21, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 9/20/2023 12:36 PM, Michael S wrote:
> PulseEvent never worked right.

PulseEvent might have worked under cooperative multitasking (i.e.
up until Windows 3).

Under cooperative multitasking, effectively, the running thread holds a
de-facto global mutex: one which prevents all other threads from
running. Yielding is like giving up that mutex.

Under cooperative multitasking, certain synchronization objects like
events effectively behave like condition variables due to the implicit
mutex.

You know that the thread which calls PulseEvent is the only one running,
and so after the operation, you know no new threads are waiting on the
event; no thread gets to run until that thread yields.

--
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/20/2023 9:46 PM, Kaz Kylheku wrote:
> On 2023-09-21, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 9/20/2023 12:36 PM, Michael S wrote:
>> PulseEvent never worked right.
>
> PulseEvent might have worked under cooperative multitasking (i.e.
> up until Windows 3).

Love your use of the word might here. It almost had to work at one time,
or else was it a forever bugged nightmare from the get go? Humm...

>
> Under cooperative multitasking, effectively, the running thread holds a
> de-facto global mutex: one which prevents all other threads from
> running. Yielding is like giving up that mutex.
>
> Under cooperative multitasking, certain synchronization objects like
> events effectively behave like condition variables due to the implicit
> mutex.
>
> You know that the thread which calls PulseEvent is the only one running,
> and so after the operation, you know no new threads are waiting on the
> event; no thread gets to run until that thread yields.
>

Touche. Sounds right, also I take careful note of your use of the word,
_might_. :^) Thanks.

Am 21.09.2023 um 06:24 schrieb Chris M. Thomasson:

> On 9/20/2023 8:42 PM, Bonita Montero wrote:

>> A yield yould be to inefficient.

> Have you heard about an adaptive backoff, different than a "traditional"
> adaptive mutex? ...

We discussed yield with periodic polling.

Am 21.09.2023 um 02:42 schrieb Pavel:

> Then there are lots of these on prevalent platforms that either cannot
> fail ...

The standard shoudln't mandate such platform capabilities. And even
if the wait itself would never fail on all platforms: a mutex' costruc-
tor is noxcept, thereby enforcing delayed creation of the kernel part
of the mutex for the slow path. This might fail on all platforms.

Am 21.09.2023 um 06:25 schrieb Chris M. Thomasson:
> On 9/20/2023 8:46 PM, Bonita Montero wrote:

>> Am 20.09.2023 um 21:36 schrieb Chris M. Thomasson:

>> A recursive lock is impossible here since the object might have
>> been partitially initialized and when coming back this partitial
>> initialization would happen again.

> A recursive would only provide a, so of, false sense of security wrt the
> infinite recursion that is present in the user code.

A recursive lock wouldn't make sense here since the object might have
beein partitially created when it re-enters the mutex which guards the
initialization.

Am 21.09.2023 um 02:22 schrieb Pavel:

> You did not even show that they use mutex at all ...

This doesn't matter, because it's clear that static initialization
can't work any other way than with a mutex. Yielding is inacceptable
and spinlocking is inacceptable for reasons I've describet multiple
times.

> This is irrelevant to the discussion, but still is wrong:

There's a non-initialized BSS segment with every executable and every
shared library. This isn't physically part of the executable file but
there's only a declared size to reserve. This block is initially com-
pletely zero. This helps the C++ implementation since every static
local object has initially an initialized-flag which is zero. This
is stored along with the object itself.

> They are only set to zero if they are not initialized explicitly.

I'm not talking about what the standad says but how it's implemented
with all operating systems that support virtual memory.