On 9/26/23 4:34 AM, Bonita Montero wrote:
> Am 26.09.2023 um 03:47 schrieb Pavel:
>
>> On *some* C++ mutex the lock() method might throw. This does not
>> matter because such C++ mutex:
>
> That's enough to expect that to be portable.
>
>> a. does not have to be used for C++ static initialization; ...
>
> I already mentioned that myself, but if there's some other kind of
> mutex this also *may* happen on some platforms. Therefore it should
> be defined this way.
>
>

Again, your argument boils down to: Even though there is a way to do it
without failure, the fact that another, "defective" way exists that
might generate an error, the Standard should be modified so that
"defective" method can be used.

Why do you keep insisting that the Standard allows sub-standard quality
of operation.

It makes no sense to allow an implementation to use the WRONG type of
mutex for the job, one that can fail, when the right type of
syncronization object exists.

You just want to allow bad implementation, maybe because that is all you
know how to make.

Am 26.09.2023 um 13:42 schrieb Richard Damon:

> Again, your argument boils down to: Even though there is a way to do
> it without failure, the fact that another, "defective" way exists that
> might generate an error, the Standard should be modified so that
> "defective" method can be used.

Pthread mutexes can be initialized statically, but then you have the
same kind of delayed inititialization - which may fail. Or if you
create the kernel part along with the initialization dynamically;
then it doesn't fit with std::mutex' constructor which is noexcept.
So in either way this operation may fail.
I don't know what's the problem for further discussions that ::lock()
simply may fail at least because of delayed initialization, on some
operating systems also because of synchronization.
And the standard can't assume a certain operation but in my opinion
even has to assume that there are platforms that even may fail on
synchronization, maybe because the kernel queue entries are allocated
dynamically or whatevery.
And it's the same for static local initialization, no matter if this
initialization actually uses a std::mutex or whatever - because in
any case there's a mutex behind to make contending threads sleeping
as documented by the stdandardd. I also mentioned many times why
yieling is inefficient and unprofessional here.

Am 26.09.2023 um 13:23 schrieb Richard Damon:

> Nope, if you do it right, a suitable synchronization object can be
> created without possibility of error.

The kernel part for the slow path is a binary semaphore. You can't
create an aribtrary number of that on any operating system. Yieling
is inefficient and I also mentioned why spin-locking is totally
inacceptable.

Am 26.09.2023 um 13:23 schrieb Richard Damon:

> But it doesn't NEED to be expected, and doing it in a way that allows
> for failure when you can do it in a way that can't fail is just being
> a bad implementation.

The slow path always is backed by a binary semaphore of the kernel.
You can't create an arbitrary number of that.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 26.09.2023 um 13:23 schrieb Richard Damon:
>
>> Nope, if you do it right, a suitable synchronization object can be
>> created without possibility of error.
>
>The kernel part for the slow path is a binary semaphore.

No, it is not.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 26.09.2023 um 13:23 schrieb Richard Damon:
>
>> But it doesn't NEED to be expected, and doing it in a way that allows
>> for failure when you can do it in a way that can't fail is just being
>> a bad implementation.
>
>The slow path always is backed by a binary semaphore of the kernel.

No, it is not. The kernel simply moves the waiter thread to a
non-runnable queue in the dispatcher until a call to 'unlock'
determines that there is a waiter and tells the kernel to
awaken it.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 26.09.2023 um 13:42 schrieb Richard Damon:
>
>> Again, your argument boils down to: Even though there is a way to do
>> it without failure, the fact that another, "defective" way exists that
>> might generate an error, the Standard should be modified so that
>> "defective" method can be used.
>
>Pthread mutexes can be initialized statically, but then you have the
>same kind of delayed inititialization - which may fail.

No, there is no delayed initialization with pthread mutexes.

Am 26.09.2023 um 17:25 schrieb Scott Lurndal:

> No, there is no delayed initialization with pthread mutexes.

There must be since you can't create a semaphore by pure assignment.

Am 26.09.2023 um 17:23 schrieb Scott Lurndal:

> No, it is not.

What else ?

Am 26.09.2023 um 17:24 schrieb Scott Lurndal:

> No, it is not. The kernel simply moves the waiter thread to
> a non-runnable queue in the dispatcher until a call to 'unlock'
> determines that there is a waiter and tells the kernel to
> awaken it.

The userspace code must tell the kernel what it its waiting for.
Mutexes are always a combination of an atomic for the fast path
and a binary semapohre for the slow path.

On Tuesday, September 26, 2023 at 6:31:13 PM UTC+3, Bonita Montero wrote:
> Am 26.09.2023 um 17:25 schrieb Scott Lurndal:
>
> > No, there is no delayed initialization with pthread mutexes.
> There must be since you can't create a semaphore by pure assignment.

I don't know how it works for pthread mutexes on any possible OS
that supports pthreads.
But I do know that Windows SRW Lock can be initialized statically.
Also I do know that it does not have to be destroyed. As long
as no threads are locked on it, it can be simply abandoned.

https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-initializesrwlock
"An unlocked SRW lock with no waiting threads is in its initial state and can be copied,
moved, and forgotten without being explicitly destroyed."

Which is a very strong hint that there is no hidden kernel object per
lock behind the scene. And very likely no hidden kernel object per any
fixed number of SRW locks.

On Tuesday, September 26, 2023 at 8:53:13 AM UTC+3, Chris M. Thomasson wrote:
> On 9/24/2023 10:04 AM, Kaz Kylheku wrote:
> > On 2023-09-24, Bonita Montero <Bonita....@gmail.com> wrote:
> >> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku:
> >>
> >>> A possible design is that each *thread* has a wait semaphore.
> >>
> >> You'd have to register the binary semaphore and register as a waiter in
> >> one atomic step. You could do that with a DCAS'd ring, but you coudn't
> >> atomically update the link pointers of the other nodes at the same
> >> time you update the roots link pointers. And you would have the deallo-
> >> cation poblem, i.e. the memory of your object may never be deallocated..
> >
> > Now you're just throwing together words you don't understand.
> >
> >> Show me your implementation !
> >
> > E.g. old LinuxThreads in glibc, circa 2000:
> >
> > https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe
> >
> > The low level __pthread_lock and __pthread_unlock functions maintain a
> > queue, using a single-word atomic CAS.
> >
> > There are suspend() and resume() functions for the waiting;
> > they are elsewhere.
> >
> > If you look in restart.h you can see that those operations are defined
> > in two different ways, both of which use signals (not a semaphore per
> > thread). A suspending thread waits for the arrival of a signal,
> > resume is done by sending a signal. That's kind of semaphore-like;
> > and POSIX real-time signals can even queue up, like a counting sem.
> >
> >> It's ridiculous because mutex are a cheap resource. And if such imple-
> >> mentation would be possible the standard shouldn't mandate it since
> >> not every platform has a DCAS.
> >
> > Things can be done in ways you havn't thought about.
> >
> > Atomic operations aren't required to achieve mutual exclusion among
> > processors that share memory.
> >
> > As someone continually insisting on having expertise in concurrency,
> > you must be familiar with the research work of Leslie Lamport?
>
> Iirc, that uses atomic loads, stores and membars. Iirc, it requires a
> #StoreLoad barrier on the SPARC. Iirc, it even requires an explicit
> membar on the x86. MFENCE, or XCHG which has the lock prefix
> automatically asserted. Humm... There is a way to get around that
> bastard #StoreLoad membar... It uses an async sync setup. The funny
> thing is that Windows has a API that can be used to actually implement
> it! Try to think of a so called, remote memory barrier, in a sense:
>
> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers
>
> There is a way to use this to get an async mutex that is kind of sort of
> akin to a read write mutex. Basically, the mutex is broken down into two
> parts. One that represents accesses that _very_ frequently called upon.
> The other one is used rather rarely. This is the async nature that can
> be exploited in rather interesting ways. I implemented some in the past
> with Dmitry Vyukov. Also, this FlushProcessWriteBuffers API can be used
> to implement other rather exotic sync schemes. They have very excellent
> performance for certain workloads. Actually, there is a way to use it to
> get a RCU in userspace and/or hazard pointers without any explicit
> #StoreLoad membars.
>
>

I would expect FlushProcessWriteBuffers() to be 2 orders of magnitude
slower than #StoreLoad membar. I could be wrong, of course, the function
is close to undocumented.

>
> >
> > For instance, the paper _A Fast Mutual Exclusion Algorithm_ [1985].
> >
> > Abstract:
> >
> > "A new solution to the mutual exclusion problem is presented that, in the
> > absence of contention, requires only seven memory accesses. It assumes
> > atomic reads and atomic writes to shared registers."
> >
> > Snipeet from Introduction which gives a clue as to the motivation:
> >
> > "Recently, there has arisen interest in building shared-memory
> > multiprocessor computers by connecting standard processors and
> > memories, with as little modification to the hardware as possible.
> > Because ordinary sequential processors and memories do not have atomic
> > test-and-set operations, it is worth investigating whether
> > shared-memory mutual exclusion algorithms are a practical alternative."
> >

Am 26.09.2023 um 17:52 schrieb Michael S:

> I don't know how it works for pthread mutexes ...

LOL

> But I do know that Windows SRW Lock can be initialized statically.

Maybe, but this is also possible with delayed initialization.

On 2023-09-26, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 26.09.2023 um 01:29 schrieb Richard Damon:
>
>> >Any platform since lock() and unlock() might throw system_error()
>> as documented.
>
> I meant to say that this is something to be expected on any platform,
> not that it actually happens.

If you're betting your business on writing some multithreading
application for a platform, you should know what actually happens on
the platform.

You probably don't choose a platform where mutexes require resources
that are only allocated on lock contention, and which can then blow up.

If you do choose that platform, you have some plan. You identify under
which conditions such a problem happens. Perhaps the system can be
configured to minimize the risk. Or perhasps there are warning signs,
like low memory, so that evasive action can be taken: clean shutdown and
restart.

Memory overcommit is enabled on most GNU/Linux system installations.
This means that memory allocations can fail not when you allocate
the memory (e.g. mmap() returning MAP_FAILED or malloc returning null)
but when you try to access the memory.

You don't necessarily combat this in the application code. Ways to deal
with it range from reducing or disabling overcommit, to just having
enough swap space for a soft landing: evasive action taken when the
system shows signs of thrashing.

Most programs at most check for up-front allocator failure; most are not
prepared to handle an access violation upon using the result of a
successful-looking allocation.

Assuming you have some mutex type which is "overcommitted" similarly,
similar reasoning applies.

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

Am 26.09.2023 um 18:46 schrieb Kaz Kylheku:

> You probably don't choose a platform where mutexes require resources
> that are only allocated on lock contention, and which can then blow up.

Contention is always possible and always expensive.

> Memory overcommit is enabled on most GNU/Linux system installations.
> This means that memory allocations can fail not when you allocate
> the memory (e.g. mmap() returning MAP_FAILED or malloc returning null)
> but when you try to access the memory.

Memory overcommit partitially bases on swappable memory. Seamphores are
in non-pageable memory inside the kernel. But I accept what you mean: if
you accept that an application can suddenly terminate because of the OOM
killer you also might accept that it would be terminated because a sin-
gle kernel semaphore coudn't be created. That may be acceptable for most
users but if there's an error code from the kernel this still should be
forwarded through your runtime for those who coudln't accept that.

On Tuesday, September 26, 2023 at 7:08:43 PM UTC+3, Bonita Montero wrote:
> Am 26.09.2023 um 17:52 schrieb Michael S:
>
> > I don't know how it works for pthread mutexes ...
>
> LOL
> > But I do know that Windows SRW Lock can be initialized statically.
> Maybe, but this is also possible with delayed initialization.

If you were reading my post up to the end you were understanding that
such possibility is extremely low.

On 2023-09-26, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 26.09.2023 um 13:42 schrieb Richard Damon:
>
>> Again, your argument boils down to: Even though there is a way to do
>> it without failure, the fact that another, "defective" way exists that
>> might generate an error, the Standard should be modified so that
>> "defective" method can be used.
>
> Pthread mutexes can be initialized statically, but then you have the
> same kind of delayed inititialization - which may fail.

It has already been explained that none of the error codes given in
POSIX for the pthread_mutex_lock function have anything to do with
resource acquisition.

--
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 Tuesday, September 26, 2023 at 8:01:00 PM UTC+3, Michael S wrote:
> On Tuesday, September 26, 2023 at 7:08:43 PM UTC+3, Bonita Montero wrote:
> > Am 26.09.2023 um 17:52 schrieb Michael S:
> >
> > > I don't know how it works for pthread mutexes ...
> >
> > LOL
> > > But I do know that Windows SRW Lock can be initialized statically.
> > Maybe, but this is also possible with delayed initialization.
> If you were reading my post up to the end you were understanding that
> such possibility is extremely low.

I meant to write 'extremely unlikely'.

On 2023-09-26, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 26.09.2023 um 17:25 schrieb Scott Lurndal:
>
>> No, there is no delayed initialization with pthread mutexes.
>
> There must be since you can't create a semaphore by pure assignment.

It has already been explained that there are multiple ways to implement
mutexes.

The approach which requires a kernel semaphore handle to be allocated
is a possibility. It would be difficult under POSIX because the
static initializer will not do that, and the lock operation is not
described as returning a resource-related error code.

In Linux, the original threads implementation in Glibc, based on
Xavier Leroy's LinuxThreads didn't use one semaphore per mutex.
It used POSIX signals to implement internal functions suspend()
and resume(). There was no kernel object to allocate.

The NPTL rewrite of the treading library was accompanied by futexes
in the kernel. Futexes also don't require allocation. Any memory
location in your virtual space can be used as a futex without any
resources being registered. Futexes were designed that way specifically
in order not to have mutex initialization fail on resource acquisition,
or waste time in the kernel, so that mutexes can be cheaply and safely.

Futexes use a fixed pool of wait queues which is allocated upfront. The
memory location is hashed to a wait queue, which it possibly shares with
unrelated futexes due to hash collisions.

There is no reason for any commercial, proprietary platform to do worse
than open source did twenty years ago, or for anyone to use it if it
sodes.

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

Kaz Kylheku <864-117-4973@kylheku.com> writes:
>On 2023-09-26, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 26.09.2023 um 13:42 schrieb Richard Damon:
>>
>>> Again, your argument boils down to: Even though there is a way to do
>>> it without failure, the fact that another, "defective" way exists that
>>> might generate an error, the Standard should be modified so that
>>> "defective" method can be used.
>>
>> Pthread mutexes can be initialized statically, but then you have the
>> same kind of delayed inititialization - which may fail.
>
>It has already been explained that none of the error codes given in
>POSIX for the pthread_mutex_lock function have anything to do with
>resource acquisition.

Although it is fair to point out that POSIX allows additional
implementation-defined error codes for POSIX interfaces, so long
as the listed conditions return the listed error codes.

That's not meant to imply that posix mutexes will ever fail, however.

Am 26.09.2023 um 19:00 schrieb Michael S:

> If you were reading my post up to the end you were understanding that
> such possibility is extremely low.

I think that's a common optimization since in many cases mutexes aren't
contended at all, thereby not needing any semaphore, or contended very
late.

Am 26.09.2023 um 19:09 schrieb Kaz Kylheku:

> In Linux, the original threads implementation in Glibc, based on
> Xavier Leroy's LinuxThreads didn't use one semaphore per mutex.
> It used POSIX signals to implement internal functions suspend()
> and resume(). There was no kernel object to allocate.

Maybe, but the C++ standard shoudn't mandate that. If you implement
a mutex yourself under Windows you'd need a kernel event or semaphore.

On 9/26/2023 9:05 AM, Michael S wrote:
> On Tuesday, September 26, 2023 at 8:53:13 AM UTC+3, Chris M. Thomasson wrote:
>> On 9/24/2023 10:04 AM, Kaz Kylheku wrote:
>>> On 2023-09-24, Bonita Montero <Bonita....@gmail.com> wrote:
>>>> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku:
>>>>
>>>>> A possible design is that each *thread* has a wait semaphore.
>>>>
>>>> You'd have to register the binary semaphore and register as a waiter in
>>>> one atomic step. You could do that with a DCAS'd ring, but you coudn't
>>>> atomically update the link pointers of the other nodes at the same
>>>> time you update the roots link pointers. And you would have the deallo-
>>>> cation poblem, i.e. the memory of your object may never be deallocated.
>>>
>>> Now you're just throwing together words you don't understand.
>>>
>>>> Show me your implementation !
>>>
>>> E.g. old LinuxThreads in glibc, circa 2000:
>>>
>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe
>>>
>>> The low level __pthread_lock and __pthread_unlock functions maintain a
>>> queue, using a single-word atomic CAS.
>>>
>>> There are suspend() and resume() functions for the waiting;
>>> they are elsewhere.
>>>
>>> If you look in restart.h you can see that those operations are defined
>>> in two different ways, both of which use signals (not a semaphore per
>>> thread). A suspending thread waits for the arrival of a signal,
>>> resume is done by sending a signal. That's kind of semaphore-like;
>>> and POSIX real-time signals can even queue up, like a counting sem.
>>>
>>>> It's ridiculous because mutex are a cheap resource. And if such imple-
>>>> mentation would be possible the standard shouldn't mandate it since
>>>> not every platform has a DCAS.
>>>
>>> Things can be done in ways you havn't thought about.
>>>
>>> Atomic operations aren't required to achieve mutual exclusion among
>>> processors that share memory.
>>>
>>> As someone continually insisting on having expertise in concurrency,
>>> you must be familiar with the research work of Leslie Lamport?
>>
>> Iirc, that uses atomic loads, stores and membars. Iirc, it requires a
>> #StoreLoad barrier on the SPARC. Iirc, it even requires an explicit
>> membar on the x86. MFENCE, or XCHG which has the lock prefix
>> automatically asserted. Humm... There is a way to get around that
>> bastard #StoreLoad membar... It uses an async sync setup. The funny
>> thing is that Windows has a API that can be used to actually implement
>> it! Try to think of a so called, remote memory barrier, in a sense:
>>
>> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers
>>
>> There is a way to use this to get an async mutex that is kind of sort of
>> akin to a read write mutex. Basically, the mutex is broken down into two
>> parts. One that represents accesses that _very_ frequently called upon.
>> The other one is used rather rarely. This is the async nature that can
>> be exploited in rather interesting ways. I implemented some in the past
>> with Dmitry Vyukov. Also, this FlushProcessWriteBuffers API can be used
>> to implement other rather exotic sync schemes. They have very excellent
>> performance for certain workloads. Actually, there is a way to use it to
>> get a RCU in userspace and/or hazard pointers without any explicit
>> #StoreLoad membars.
>>
>>
>
> I would expect FlushProcessWriteBuffers() to be 2 orders of magnitude
> slower than #StoreLoad membar. I could be wrong, of course, the function
> is close to undocumented.

FlushProcessWriteBuffers() can be used to gain a quiescent state wrt
memory visibility for some exotic async algorithms, it is called in
certain places and is RARE. However, on the other hand, having to use a
#StoreLoad membar on the fast path is not good. Keep in mind that this
is meant to handle a store followed by a load to another location
scenario. We need to honor the #StoreLoad relationship for this type of
setup for these types of algorithms. For instance, hazard pointers
require a #StoreLoad, however there is a way to eliminate them using
some special magic wrt RCU...

My friend Joe Seigh created SMR+RCU to gain this. SMR is hazard
pointers. Now, keep in mind that these are very "specialized" algorithms
that try to make certain workloads MUCH faster and way more efficient.
They work for that.

Also, keep in mind that a normal mutex does not require #StoreLoad. Only
acquire and release:

acquire = #LoadStore | #LoadLoad
release = #LoadStore | #StoreStore

In SPARC parlance. For instance, an atomic store on x86 automatically
implies release. Btw, have you ever worked with SPARC in RMO mode? Its
fun because its so weak.

I still need to find that old paper called QPI, if I remember correctly.
It should still be out there. I will try to find it sometime today.

It think is was from Dice wrt a Java VM. David Dice? Damn I cannot
remember it right now. Sorry. ;^o

[...]

On 9/26/2023 8:31 AM, Bonita Montero wrote:
> Am 26.09.2023 um 17:23 schrieb Scott Lurndal:
>
>> No, it is not.
>
> What else ?
>

Sigh.

On 9/26/2023 4:23 AM, Richard Damon wrote:
> On 9/26/23 5:11 AM, Bonita Montero wrote:
>> Am 26.09.2023 um 06:52 schrieb Kaz Kylheku:
>>
>>> Not in a correct program which is free of misuses of locks!
>>
>> This is your name based on individual operating systems.
>> This assumption is not portable.
>>
>>> If you're getting a system_error from a mutex operation, you should
>>> debug that. ...
>>
>> The constructor is noexcept, so locking has to do the delayed
>> initialization for the slow path on contention. This delayed
>> initialization can fail.
>>
>
> Nope, if you do it right, a suitable synchronization object can be
> created without possibility of error.

Bonita needs to learn that there are ways to, do it right. For some damn
reason, it reminds me of the following crazy song from Daft Punk.
Actually, Daft Punk reminds me of Bonita for some strange reason... Robots?

https://youtu.be/LL-gyhZVvx0

Everybody will be dancing when we are doing it right...

;^)

>
> Thus, doing something that might fail is just wrong.
>
> You seem to like failing at what you try to do.