Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 22.09.2023 um 04:58 schrieb Pavel:
>
>> It **is** the job of the standard authors to assume what elementary
>> operations can and what cannot fail and build their specs upon that.
>
>Mutex synchronization can fail at least in C++ because of delayed
>initialization since the constructor itself of mutex is noexcept.

Why on earth would the run-time/dynamic loader use a C++ mutex
instead of an implementation-defined primitive (e.g. pthread_once,
pthread_mutex_t) which are easily statically initalized?

Am 22.09.2023 um 19:56 schrieb Scott Lurndal:

> Why on earth would the run-time/dynamic loader use a C++ mutex
> instead of an implementation-defined primitive (e.g. pthread_once,
> pthread_mutex_t) which are easily statically initalized?

pthread_mutex_init() can fail so you can't used it inside the std::mutex
constructor. Using pthread_mutex_init() delayed inside ::lock is too
late because you need a locking-counter/-flag at this moment, but this
is created internally along with pthread_mutex_init().

On 2023-09-22, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 22.09.2023 um 19:30 schrieb Chris M. Thomasson:
>
>> Why do you say that!? A futex does not make the user code create any
>> kernel resources. You are a fairly stubborn person! :^)
>
> A futex is a replacement for the slow path, replacing a binary
> semaphore. It requires to make the futexes's address to be read
> -only to trap accesses and it requires a waiter's queue inside
> the kernel.

Futexes do not trap accesses. That would make them too slow to be
useful, and defeat their entire purpose, which is to avoid unnecessary
trips to the kernel! How can you not have an intuition for this,
given all the multithreading know-how and experience you claim to have?

The kernel does not know when a futex location is touched; it
is not informed.

That's why there is an explicit futex wake operation.

> Your misconception is that you think the futex is pure userspace,
> but the difference is just that there's no explicit kernel-call
> but a MMU-trap, which is faster on most CPUs than a explicit
> kernel-call. So a futex is not possible without a MMU, documented
> here: https://bugzilla.kernel.org/show_bug.cgi?id=78881

The bug is reported against some MMU-less sytem, claiming that
FUTEX_WAIT and FUTEX_WAKE are returning -EFAULT.
https://bugzilla.kernel.org/show_bug.cgi?id=78881

The bug reporter acknowledges that the issue does not affect
private futexes; i.e. they are working on their MMU-less system!

It's happening in the get_futex_key function, which has to
obtain a stable hash key from a futex address.

Futexes interact with virtual memory because virtual memory
has the potential to create aliases.

The same futex location can be shared memory which can exist
at different addresses in different processes (or even
the same process).

The same futex can have more than one virtual address. See the problem?
The futex has to hash to the same wait queue, in spite of having
different virtual addresses. So what that means is that we cannot just
naively hash the virtual address to get a futex key for the hash.

The above bug says that this resolution is not working.

The bug was opened nine years ago and is still NEW probably because it
is not easily fixable. Without a MMU, futex sharing via shared memory
doesn't make sense. About all you can do is report a different error
than -EFAULT, like -EOPNOTSUPP or whatever.

(I'm surprised nobody replied to the bug to at least say that.)

--
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 2023-09-22, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 22.09.2023 um 19:56 schrieb Scott Lurndal:
>
>> Why on earth would the run-time/dynamic loader use a C++ mutex
>> instead of an implementation-defined primitive (e.g. pthread_once,
>> pthread_mutex_t) which are easily statically initalized?
>
> pthread_mutex_init() can fail so you can't used it inside the std::mutex
> constructor.

POSIX provides a PTHREAD_MUTEX_INITIALIZER which lets you do just this:

pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;

In a C++ mutex class based on pthread_mutex_t we can do

class cpp_mutex {
private:
pthread_mutex_t mtx;

public:
cpp_mutex() : mtx(PTHREAD_MUTEX_INITIALIZER)
{
}
};

(Note that the POSIX standard used to say that the
PTHREAD_MUTEX_INITIALIZER could be used for statically allocated
mutexes. That wording no longer appears.)

pthread_mutex_init can fail, but usually doesn't. If you use NULL
attributes (i.e. not making any funny mutex type, like process-shared
robust or whatever) and haven't done anything wrong, you will not get a
nonzero return.

The API allows for resource-related errors like EAGAIN, but a mutex
created with default attributes will pretty much be the same as
one set up with PTHREAD_MUTEX_INITIALIZER. Implementations have to
support that and so they figure out how to have a basic mutex that
doesn't fail on construction.

Note that resource allocation cannot be deferred to lock acquisition
time; no resource-related error codes are specified for
pthread_mutex_lock.

See POSIX here:

https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html

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

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 22.09.2023 um 19:56 schrieb Scott Lurndal:
>
>> Why on earth would the run-time/dynamic loader use a C++ mutex
>> instead of an implementation-defined primitive (e.g. pthread_once,
>> pthread_mutex_t) which are easily statically initalized?
>
>pthread_mutex_init() can fail

That is beside the point. The mutex can be statically initialized
and the pthread_mutex_init call is unnecessary. You've been informed
of this point at least a half dozen times in this thread alone.

SYNOPSIS
#include <pthread.h>

int pthread_mutex_destroy(pthread_mutex_t *mutex);
int pthread_mutex_init(pthread_mutex_t *restrict mutex,
const pthread_mutexattr_t *restrict attr);
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

On 9/22/23 8:15 AM, Bonita Montero wrote:
> Am 22.09.2023 um 13:31 schrieb Richard Damon:
>
>> Just shows that you don't actually know what we are talking about.
>
> We're talking about if everything different like a mutex is acceptable
> here. And it isn't. Yielding might have a too high delay under load
> and spinning is dangerous in userspace because of what I've said.
>

Which, since it has been explained WHY your arguments are just wrong,
showing that you don't know what you are talking about, since all your
arguements are against "Strawmen" and not the actual thing being talked
about, you are just showing your ignorance.

You seem to be claiming that because you can't figure out a reasonable
way to do it with what you understand, the Standard needs to be changed
to allow provide lessor promises to the programmer.

Since there ARE implementation that actually meet the requirements, you
are obviously wrong that they can't be meet with a "reasonable" performance.

The fact that you are too stupid to understand how these things actually
work and give performant results doesn't mean they don't do it. The fact
that they do shows your ignorance.

On 9/21/2023 7:29 PM, Bonita Montero wrote:
> Am 21.09.2023 um 20:25 schrieb Chris M. Thomasson:
>> On 9/21/2023 7:17 AM, Bonita Montero wrote:
>>> Am 21.09.2023 um 15:05 schrieb David Brown:
>>>
>>>> "Yield" won't take a timeslice unless there is something else of the
>>>> same priority, waiting to run on the same core. ...
>>>
>>> Ok, you're right, but the code would be still unacceptable under load.
>>>
>>
>> Wait, are you talking about a _pure_ spin lock in user space here?
>> For some reason you seem to be struggling with adaptive backoffs, ...
>
> No, we were discussing yielding.
>
>

What about an algorithm that can try to do some other non related work
instead of yielding? I remember learning about this technique many moons
ago over on comp.arch. I think it was from Lynn and Ann Wheeler? They
just happen to be VERY smart and saturated with experience. I cannot
remember their last name right now it think its Wheeler. Argh! Those
posts might be hard to find.

On 9/21/2023 7:29 PM, Bonita Montero wrote:
> Am 21.09.2023 um 20:21 schrieb Chris M. Thomasson:
>> On 9/21/2023 5:40 AM, Bonita Montero wrote:
>>> Am 21.09.2023 um 13:36 schrieb Richard Damon:
>>>
>>>> Why?
>>>
>>> Because the initialization might only take a microsecond or less
>>> and a yield is a full timeslice, on Linux and Windows usually one
>>> millisecond.
>>
>> An adaptive backoff can be a mixture of the PAUSE instruction aka x86,
>> and yield wrt the OS.
>
> Do you have a mental disorder ?
> We were discussing yielding.
>

An adaptive backoff is about yielding in interesting ways. Wow, you are
trying so hard to be a special kind of stubborn person right now. For
some reason, I would not trust you to create an adaptive backoff simply
because you seem to be radically confused about synchronization in general.

On 9/22/2023 10:50 AM, Bonita Montero wrote:
> Am 22.09.2023 um 19:41 schrieb Chris M. Thomasson:
>
>> Afaict, Bonita needs to study up on a great many things when it comes
>> to synchronization. Sometimes, I think Bonita is actually trolling on
>> purpose... Humm...
>
> The problem is not that I don't understand synchronization,

Hummm... I can read what you post here. There are a lot of issues.

> the problem
> is that I don't accept your objections where they don't fit the context.

Oh please. Man. Shit. You are the one that seems to enjoy to torching
scarecrows at the stake, and other types of straw men. Yikes!

I can read your posts, and I gather that you still have a LOT to learn.

On 9/22/2023 3:22 PM, Scott Lurndal wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 22.09.2023 um 19:56 schrieb Scott Lurndal:
>>
>>> Why on earth would the run-time/dynamic loader use a C++ mutex
>>> instead of an implementation-defined primitive (e.g. pthread_once,
>>> pthread_mutex_t) which are easily statically initalized?
>>
>> pthread_mutex_init() can fail
>
> That is beside the point. The mutex can be statically initialized
> and the pthread_mutex_init call is unnecessary. You've been informed
> of this point at least a half dozen times in this thread alone.
>
> SYNOPSIS
> #include <pthread.h>
>
> int pthread_mutex_destroy(pthread_mutex_t *mutex);
> int pthread_mutex_init(pthread_mutex_t *restrict mutex,
> const pthread_mutexattr_t *restrict attr);
> pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
>

Bonita sure seems to be very set in its ways. Since this is not
something it knows about, it can tend to get fairly angry and lash out
with verbal assaults.

Bonita Montero wrote:
> Am 22.09.2023 um 04:25 schrieb Pavel:
>
>> What are you trying to prove? ..
>
> THat mem is initiallly zero, although this isn't guarenteed for
> static fundamental types.
>
Nice try. Some memory is initialized to zero, some is not. None of this
proves that C++ standard spec of static initialization should be changed.

Bonita Montero wrote:
> Am 22.09.2023 um 04:21 schrieb Pavel:
>
>> How does the above prove your wrong point that initialization of
>> static synchronization primitives always may fail? ...
>
> The mutex is created along with the static object from zeroed memory
> whene there's contention. At least this may fail. And with Windows
> the synchronization may also fail.
Neither fails if implemented propertly.

POSIX synchronization primitives are not created, they are initialized.
Incidentally, the easiest way to initialize mutex and pthread_once_t is
to constant-initialize them to what is defined on Linux as zero memory.
This cannot fail for static mutex or pthread_once_t.

How can this constant initialization of INIT_ONCE primitive on Windows fail?
static INIT_ONCE io = INIT_ONCE_STATIC_INIT;

How can a call to InitOnceExecuteOnce on propertly initialized INIT_ONCE
object fail?

Right, they cannot. So stop making false claims.

Bonita Montero wrote:
> Am 22.09.2023 um 04:50 schrieb Pavel:
>
>> A "deferred" initialization of a static sync primitive used to sync
>> static initialization of a C++ object is not only unnecessary
>> (constant initialization is enough) but also would be useless if used.
>> Because how would you correctly synchronize this "deferred"
>> initialization itself if the initialization of the static object is
>> requested concurrently from 2 threads. You should stop invent and talk
>> nonsense.
>
> A lock may be never contended or contended very lately, so that
> delayed allocation of the kernel semaphore may make sense.
>
No, it cannot make sense. A "deferred" initialization of a static
synchronization primitive is itself not thread-safe; hence it cannot be
used to initialize a static C++ object in a thread-safe manner. Plain
and simple.

Bonita Montero wrote:
> Am 22.09.2023 um 04:58 schrieb Pavel:
>
>> It **is** the job of the standard authors to assume what elementary
>> operations can and what cannot fail and build their specs upon that.
>
> Mutex synchronization can fail at least in C++
for some mutex it may fail, for some not. C++ standard never says that
std::mutex can fail. This is irrelevant because C++ once_flag
initialization cannot fail and the standard specifically advises using
other synchronization to ensure that mutex objects are initialized and
visible to other threads

> because of delayed
> initialization
"delayed" or "deferred" initialization of synchronization primitives
that can be used to initialize static C++ object is entirely your
fantasy. It cannot be used for this purpose, period.

> since the constructor itself of mutex is noexcept.
irrelevant. std::once_flag constructor is noexcept and once_flag
initialization cannot fail.

> It's the same with whatever is used for static initializatiionsince
> the mutex-ish data structure is created when there's contention.
Wrong. std::once_flag constructor is noexcept and once_flag
initialization cannot fail.

On 9/22/2023 7:15 PM, Pavel wrote:
> Bonita Montero wrote:
>> Am 22.09.2023 um 04:21 schrieb Pavel:
>>
>>> How does the above prove your wrong point that initialization of
>>> static synchronization primitives always may fail? ...
>>
>> The mutex is created along with the static object from zeroed memory
>> whene there's contention. At least this may fail. And with Windows
>> the synchronization may also fail.
> Neither fails if implemented propertly.
>
> POSIX synchronization primitives are not created, they are initialized.
> Incidentally, the easiest way to initialize mutex and pthread_once_t is
> to constant-initialize them to what is defined on Linux as zero memory.
> This cannot fail for static mutex or pthread_once_t.
>
> How can this constant initialization of INIT_ONCE primitive on Windows
> fail?
> static INIT_ONCE io = INIT_ONCE_STATIC_INIT;
>
> How can a call to InitOnceExecuteOnce on propertly initialized INIT_ONCE
> object fail?
>
> Right, they cannot. So stop making false claims.
>

Ding! You are correct.

On 9/22/2023 6:58 PM, Pavel wrote:
> Bonita Montero wrote:
>> Am 22.09.2023 um 04:25 schrieb Pavel:
>>
>>> What are you trying to prove? ..
>>
>> THat mem is initiallly zero, although this isn't guarenteed for
>> static fundamental types.
>>
> Nice try. Some memory is initialized to zero, some is not. None of this
> proves that C++ standard spec of static initialization should be changed.

Afaict, Bonita is not stupid at all. That's the odd ball part. Humm...

Am 23.09.2023 um 00:31 schrieb Richard Damon:

> The fact that you are too stupid to understand how these things actually
> work and give performant results doesn't mean they don't do it. The fact
> that they do shows your ignorance.

Yielding at this place and spin-locking in userspace is unprofessional.

Am 22.09.2023 um 20:38 schrieb Kaz Kylheku:

> POSIX provides a PTHREAD_MUTEX_INITIALIZER which lets you do just this:
> pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;

Ok, then Posix threads also can do delayed initialization of the
kernel part for the slow path. And I see that InitializeCriticalSection
doesn't fail but EnterCriticalSection can, i.e. there's also delayed
initialization.

Am 23.09.2023 um 00:22 schrieb Scott Lurndal:

> That is beside the point. The mutex can be statically initialized
> ...

This depends on the program which uses the mutex.

Am 23.09.2023 um 04:50 schrieb Pavel:

> for some mutex it may fail, for some not. C++ standard never says that
> std::mutex can fail. ...

std::mutex::lock() can throw a system_error.

> "delayed" or "deferred" initialization of synchronization primitives
> that can be used to initialize static C++ object is entirely your
> fantasy. It cannot be used for this purpose, period.

The mutex' constructor doesn't throw, so there must be delayed
initialization. But as we've seen recently pthread Mutexes also
allow delayed initialization of the slow path and Win32 always
does the same.

On 9/22/2023 9:41 PM, Bonita Montero wrote:
> Am 22.09.2023 um 20:38 schrieb Kaz Kylheku:
>
>> POSIX provides a PTHREAD_MUTEX_INITIALIZER which lets you do just this:
>>    pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;
>
> Ok, then Posix threads also can do delayed initialization of the
> kernel  part for the slow path. And I see that InitializeCriticalSection
> doesn't fail but EnterCriticalSection can, i.e. there's also delayed
> initialization.
>

POSIX is a standard, EnterCriticalSection is a mutex for windows. You
need to check this out, wrt windows:

https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitonaddress

POSIX needs to work with the compiler and vise versa, like a system, or
else the contract is broken. A system that wants to allow itself to
adhere to POSIX must make sure it works within the POSIX std.

On 9/22/2023 9:38 PM, Bonita Montero wrote:
> Am 23.09.2023 um 00:31 schrieb Richard Damon:
>
>> The fact that you are too stupid to understand how these things
>> actually work and give performant results doesn't mean they don't do
>> it. The fact that they do shows your ignorance.
>
> Yielding at this place and spin-locking in userspace is unprofessional.
>

It's "unprofessional" in this place to, basically, claim that you know
what you are doing, when you really do not?

On 9/21/2023 11:42 AM, Kaz Kylheku wrote:
> On 2023-09-21, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 9/21/2023 5:40 AM, Bonita Montero wrote:
>>> Am 21.09.2023 um 13:36 schrieb Richard Damon:
>>>
>>>> Why?
>>>
>>> Because the initialization might only take a microsecond or less
>>> and a yield is a full timeslice, on Linux and Windows usually one
>>> millisecond.
>>
>> An adaptive backoff can be a mixture of the PAUSE instruction aka x86,
>> and yield wrt the OS.
>
> Ideally there shouldn't be a difference? In user mode execution, PAUSE
> should be a privileged instruction. User space must not pause the
> machine until an interrupt occurs. The privileged instruction will trap
> to the kernel, where it becomes equivalent to a yield().
>
> In the kernel, the lowest-priority idle task might execute that
> instruction in a loop: the real one, not the trap.
>
> When the scheduler determines there is truly nothing to do then it is
> legitimate to dispatch an idle task which suspends the processor until
> an external event.
>

I have seen experimental adaptive backoff schemes on several platforms,
windows one rings a bell, it used used PAUSE, SwitchToThread, Sleep(0),
and even Sleep(1), before it waited in the kernel. It kept statistics,
and tried to see that if the adaptive backoff can be used to increase
performance and reduce the number of times it waited in the kernel. For
certain workloads, it worked out pretty good, for others not so much...

Am 23.09.2023 um 07:59 schrieb Chris M. Thomasson:
> On 9/22/2023 9:41 PM, Bonita Montero wrote:
>> Am 22.09.2023 um 20:38 schrieb Kaz Kylheku:
>>
>>> POSIX provides a PTHREAD_MUTEX_INITIALIZER which lets you do just this:
>>>    pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;
>>
>> Ok, then Posix threads also can do delayed initialization of the
>> kernel  part for the slow path. And I see that InitializeCriticalSection
>> doesn't fail but EnterCriticalSection can, i.e. there's also delayed
>> initialization.
>>
>
> POSIX is a standard, EnterCriticalSection is a mutex for windows.
> You need to check this out, wrt windows:

I'm talking of common properties of both.

>
> https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitonaddress
>
> POSIX needs to work with the compiler and vise versa, like a system, or
> else the contract is broken. A system that wants to allow itself to
> adhere to POSIX must make sure it works within the POSIX std.

Am 23.09.2023 um 06:41 schrieb Bonita Montero:

> Ok, then Posix threads also can do delayed initialization of the
> kernel  part for the slow path. And I see that InitializeCriticalSection
> doesn't fail but EnterCriticalSection can, i.e. there's also delayed
> initialization.

This is how a mutex whose constructor is noexcept works.
The code demonstrates the delayed initialization of the slow path:

#if defined(_WIN32)
#include <Windows.h>
#elif defined(__unix__)
#include <fcntl.h>
#include <semaphore.h>
#endif
#include <iostream>
#include <atomic>
#include <cassert>
#include <system_error>
#include <memory>

using namespace std;

struct DelayedMutex
{ DelayedMutex() noexcept;
~DelayedMutex();
void lock();
void unlock();
private:
#if defined(_WIN32)
HANDLE getSem();
#elif defined(__unix__)
sem_t *getSem();
#endif
atomic<unsigned> m_lockCounter;
#if defined(_WIN32)
static_assert(atomic<HANDLE>::is_always_lock_free, "atomic<HANDLE> must
be lock-free");
atomic<HANDLE> m_hSem;
#elif defined(__unix__)
atomic<sem_t *> m_sem;
#endif
};

DelayedMutex::DelayedMutex() noexcept :
m_lockCounter( 0 ),
#if defined(_WIN32)
m_hSem( NULL )
#elif defined(__unix__)
m_sem( nullptr )
#endif
{ }

DelayedMutex::~DelayedMutex()
{ assert(!m_lockCounter.load( memory_order_relaxed ));
#if defined(_WIN32)
HANDLE hSem = m_hSem.load( memory_order_relaxed );
if( hSem )
CloseHandle( hSem );
#elif defined(__unix__)
sem_t *sem = m_sem.load( memory_order_relaxed );
if( sem )
sem_destroy( sem ),
delete sem;
#endif
}

void DelayedMutex::lock()
{ unsigned before = m_lockCounter.fetch_add( 1, memory_order_acquire );
assert(before != -1);
if( !before ) [[likely]]
return;
#if defined(_WIN32)
if( WaitForSingleObject( getSem(), INFINITE ) != WAIT_OBJECT_0 )
[[unlikely]]
#elif defined(__unix__)
if( sem_wait( getSem() ) ) [[unlikely]]
#endif
terminate();
}

void DelayedMutex::unlock()
{ unsigned before = m_lockCounter.fetch_sub( 1, memory_order_acquire );
assert(before >= 1);
if( before == 1 ) [[likely]]
return;
#if defined(_WIN32)
if( !SetEvent( getSem() ) )[[unlikely]]
#elif defined(__unix__)
if( sem_post( getSem() ) ) [[unlikely]]
#endif
terminate();
}

#if defined(_WIN32)
HANDLE DelayedMutex::getSem()
{ HANDLE hSem = m_hSem.load( memory_order_relaxed );
if( hSem ) [[likely]]
return hSem;
hSem = CreateEventA( nullptr, FALSE, FALSE, nullptr );
if( !hSem ) [[unlikely]]
throw system_error( GetLastError(), system_category(), "kernel
semaphore creation failed" );
HANDLE hSemExpected = NULL;
if( !m_hSem.compare_exchange_weak( hSemExpected, hSem,
memory_order_relaxed, memory_order_relaxed ) ) [[unlikely]]
CloseHandle( hSem ),
hSem = hSemExpected;
return hSem;
} #elif defined(__unix__)
sem_t *DelayedMutex::getSem()
{ sem_t *sem = m_sem.load( memory_order_relaxed );
if( sem ) [[likely]]
return sem;
unique_ptr<sem_t> newSem( make_unique<sem_t>() );
if( sem_init( &*newSem, 0, 0 ) ) [[unlikely]]
throw system_error( errno, system_category(), "kernel semaphore
creation failed" );
sem_t *semExpected = nullptr;
if( m_sem.compare_exchange_weak( semExpected, &*newSem,
memory_order_relaxed, memory_order_relaxed ) ) [[likely]]
sem = &*newSem,
newSem.release();
else
sem_destroy( &*newSem ),
sem = semExpected;
return sem;
} #endif

int main()
{ }