On 9/17/23 2:32 PM, Bonita Montero wrote:
> Am 17.09.2023 um 20:26 schrieb Richard Damon:
>
>> You have it backwards. If the mutex object actually CAN fail, than any
>> implementation that uses them, and don'y handle the failure, is
>> incorrect.
>
> The standard should allow an implementation that fails and have
> a way to handle that; a system_error would be the most appropiate
> way.

Nope, if a system can't actually find a way to reliably do file scope
initialization, it shouldn't be able to call itself conforming.

Yes, you can use some faster but fail-prone methods first, but if they
fail then you need to fall back to (possibly) slower but reliable methods.

On 9/17/23 2:06 PM, Bonita Montero wrote:
> Am 17.09.2023 um 19:37 schrieb Pavel:
>
>> Bonita Montero wrote:
>>> As I've shown with my program MSVC, libstdc++ (g++) and libc++ (clang++)
>>> have per object mutexes.
>
>> No your program does not show this. ...
>
> Of course I show this. I've got a generic lambda and each thread
> gets its own instantiation of the calling operator of that lambda,
> thereby having _individual_ static objects per calling operator.
>

You haven't actually looked at HOW the code actually does what it does,
so you haven't shown anything (except your own limitations in
understanding code).

On 9/17/2023 11:30 AM, Bonita Montero wrote:
> Am 17.09.2023 um 20:25 schrieb Chris M. Thomasson:
>
>> Getting WAIT_FAILED means something really bad has hit the fan.
>> WAIT_ABANDONED is fine and can be handled, akin to EOWNERDEAD.
>> This is for inter-process robust sync.
>
> It's unspecified why this happens.
>
>> A futex does not need to create new kernel resources on demand.
>> They are already there.
>
> Read the Linux futex paper. The page which holds the futex is locked
> and there's a wating queue for contenders inside the kernel.
>
>

They depend on an atomic predicate in userspace. The kernel resources do
not get created on demand such that they can fail to be created, because
they are already there. The kernel only gets used when the userspace
algorihtm needs to wait, aka, a slow path...

std::uintptr_t can be used as a futex. The userspace code does not need
to create anything in the kernel. Humm... You sound like you are not all
that familiar with them. So be it.

Am 17.09.2023 um 20:27 schrieb Chris M. Thomasson:
> On 9/17/2023 11:06 AM, Bonita Montero wrote:
>> Am 17.09.2023 um 19:37 schrieb Pavel:
>>
>>> Bonita Montero wrote:
>>>> As I've shown with my program MSVC, libstdc++ (g++) and libc++
>>>> (clang++)
>>>> have per object mutexes.
>>
>>> No your program does not show this. ...
>>
>> Of course I show this. I've got a generic lambda and each thread
>> gets its own instantiation of the calling operator of that lambda,
>> thereby having _individual_ static objects per calling operator.
>>
>
> Sigh.

Here's the code again:

#include <iostream>
#include <utility>
#include <vector>
#include <thread>

using namespace std;

int main()
{ struct InitSleep
{
InitSleep()
{
this_thread::sleep_for( 1s );
}
};
constexpr unsigned N_THREADS = 100;
auto unroll = []<size_t ... Indices>( index_sequence<Indices ...>, auto
fn )
{
(fn.template operator ()<Indices>(), ...);
};
vector<jthread> threads;
threads.reserve( N_THREADS );
unroll( make_index_sequence<N_THREADS>(),
[&]<size_t T>()
{
threads.emplace_back( []( auto )
{
static InitSleep is;
}, integral_constant<size_t, T>() );
} );
}

The calling operator of the theads's function object is generic
and instantited once per T. So the static is object is individual
per each instantiation of the calling operator. The above code
takes about one second with MSVC, g++ (libstdc++) and clan++
(libc++), so there's an individual mutex per calling operator
of the above lambda.
So if you handle it that way creating synchronization and the
synchronization may fail. The standard shoud support appropriate
error handling if initialization is done that fine grained like
with the mentioned implementations.

On 9/17/2023 11:32 AM, Bonita Montero wrote:
> Am 17.09.2023 um 20:26 schrieb Richard Damon:
>
>> You have it backwards. If the mutex object actually CAN fail, than any
>> implementation that uses them, and don'y handle the failure, is
>> incorrect.
>
> The standard should allow an implementation that fails and have
> a way to handle that; a system_error would be the most appropiate
> way.

Sigh.

Am 17.09.2023 um 20:42 schrieb Chris M. Thomasson:

> They depend on an atomic predicate in userspace. ..

This is not really userspace if the page accesses are trapped to have
a faster way inside the kernel.

Am 17.09.2023 um 20:35 schrieb Richard Damon:

> Nope, if a system can't actually find a way to reliably do file scope
> initialization, it shouldn't be able to call itself conforming.

global static objects are a different issue. They're not created with
contention since they're created before main. I was concerned about
static local objects. And the way I suggested would provide a bit
cleaner initialization.

On 9/17/2023 11:43 AM, Bonita Montero wrote:
> Am 17.09.2023 um 20:27 schrieb Chris M. Thomasson:
>> On 9/17/2023 11:06 AM, Bonita Montero wrote:
>>> Am 17.09.2023 um 19:37 schrieb Pavel:
>>>
>>>> Bonita Montero wrote:
>>>>> As I've shown with my program MSVC, libstdc++ (g++) and libc++
>>>>> (clang++)
>>>>> have per object mutexes.
>>>
>>>> No your program does not show this. ...
>>>
>>> Of course I show this. I've got a generic lambda and each thread
>>> gets its own instantiation of the calling operator of that lambda,
>>> thereby having _individual_ static objects per calling operator.
>>>
>>
>> Sigh.
>
> Here's the code again:
>
> #include <iostream>
> #include <utility>
> #include <vector>
> #include <thread>
>
> using namespace std;
>
> int main()
> {
>     struct InitSleep
>     {
>         InitSleep()
>         {
>             this_thread::sleep_for( 1s );
>         }
>     };
>     constexpr unsigned N_THREADS = 100;
>     auto unroll = []<size_t ... Indices>( index_sequence<Indices ...>,
> auto fn )
>     {
>         (fn.template operator ()<Indices>(), ...);
>     };
>     vector<jthread> threads;
>     threads.reserve( N_THREADS );
>     unroll( make_index_sequence<N_THREADS>(),
>         [&]<size_t T>()
>         {
>             threads.emplace_back( []( auto )
>                 {
>                     static InitSleep is;
>                 }, integral_constant<size_t, T>() );
>         } );
> }
>
> The calling operator of the theads's function object is generic
> and instantited once per T. So the static is object is individual
> per each instantiation of the calling operator. The above code
> takes about one second with MSVC, g++ (libstdc++) and clan++
> (libc++), so there's an individual mutex per calling operator
> of the above lambda.

Sigh.

> So if you handle it that way creating synchronization and the
> synchronization may fail. The standard shoud support appropriate
> error handling if initialization is done that fine grained like
> with the mentioned implementations.
>
>
>
>

On 2023-09-17, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 17.09.2023 um 19:40 schrieb Richard Damon:
>
>> By the Standard, static initialization isn't allowed to have a
>> "syncronization issue", ...
>
> If you implement it that way like MSVC, libc++ and libstdc++ with
> a mutex per object synchronization can fail. And the standard should
> define what happens then.

When mutexes fail, it is due to bugs in the application. In that case,
if that happens at global init time, the program can just abort.

In POSIX, the only legitimate external error in a mutex operation
occurs when a mutex is process shared, and another process has locked
it and then terminated. This situation is indicated to the caller of
pthread_mutex_lock which is essentially tasked with cleaning up the
situation somehow. Even that is a programming error though: a bug in
the multi-process application that its components are failing while
holding a shared mutex. It is nto a genuine external condition like
"file not found", "permission denied" or "network down" or "I/O error".

All the other error situations in a mutex are local error checks for
debugging. Those situations should not happen, among them being:

- unlocking a mutex which is not owned by the calling thread.

- deadlock

- recursively locking a mutex that is not recursive

- anything else, like using a corrupt mutex.

A correctly used mutex in a correct program free of deadlocks
does not fail.

If a debugging mutex is used for thread-safe once-only static inits, it
would be acceptable to abort if that mutex indicates a problem.

Turning that into an exception would be fine, though there likely
isn't any useful way to recover from it. Leaving it unhandled would
be the best.

Most attempts in C++ code to deal with a program logic error via
exception handling only succeed in making it harder to debug,
because unwinding destroys vital information about the problem.

--
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 17.09.2023 um 20:37 schrieb Richard Damon:

> You haven't actually looked at HOW the code actually does what it does,
> so you haven't shown anything (except your own limitations in
> understanding code).

I don't need to check that. I've proven that each static local
object has its own initialization and not a shared mutex because
the code runs exactly one second. So if you have an indivivual
mutex per static local object this synchronization may fail.
A pre-allocated global mutex for all static local initialization
may not fail, but the standard should honour platforms where
this actually can happen.

On 9/17/2023 11:44 AM, Bonita Montero wrote:
> Am 17.09.2023 um 20:42 schrieb Chris M. Thomasson:
>
>> They depend on an atomic predicate in userspace. ..
>
> This is not really userspace if the page accesses are trapped to have
> a faster way inside the kernel.
>

Huh? Futexes are designed to allow userspace to use them efficiently.

On 9/17/2023 11:44 AM, Bonita Montero wrote:
> Am 17.09.2023 um 20:42 schrieb Chris M. Thomasson:
>
>> They depend on an atomic predicate in userspace. ..
>
> This is not really userspace if the page accesses are trapped to have
> a faster way inside the kernel.
>

What is the difference between a fast-path and a slow-path wrt
synchronization algorithms?

Am 17.09.2023 um 20:49 schrieb Kaz Kylheku:

> When mutexes fail, it is due to bugs in the application. In that case,
> if that happens at global init time, the program can just abort.

C++ mutexes always have a delayed initialitation since the constructor
is noexcept. So the semaphore behind the mutex which backs contention
is created on synchonzation, which may fail.

> In POSIX, ..

It doesn't matter what a specific operating system says about that,
the standard should honour a failure in this case, even more if you
have deferred initialization with C++ mutexes.

Rest unread.

On 9/17/2023 11:49 AM, Bonita Montero wrote:
> Am 17.09.2023 um 20:37 schrieb Richard Damon:
>
>> You haven't actually looked at HOW the code actually does what it
>> does, so you haven't shown anything (except your own limitations in
>> understanding code).
>
> I don't need to check that. I've proven that each static local
> object has its own initialization and not a shared mutex because
> the code runs exactly one second.

Huh? wow.

> So if you have an indivivual
> mutex per static local object this synchronization may fail.

WOW!

> A pre-allocated global mutex for all static local initialization
> may not fail, but the standard should honour platforms where
> this actually can happen.
>

Cough...

Am 17.09.2023 um 20:50 schrieb Chris M. Thomasson:
> On 9/17/2023 11:44 AM, Bonita Montero wrote:
>> Am 17.09.2023 um 20:42 schrieb Chris M. Thomasson:
>>
>>> They depend on an atomic predicate in userspace. ..
>>
>> This is not really userspace if the page accesses are trapped to have
>> a faster way inside the kernel.
>>
>
> Huh? Futexes are designed to allow userspace to use them efficiently.

You don't understand futexes. If you have contention
there's still a kernel-transition through a MMU trap.

On 9/17/2023 11:51 AM, Bonita Montero wrote:
> Am 17.09.2023 um 20:49 schrieb Kaz Kylheku:
>
>> When mutexes fail, it is due to bugs in the application.  In that case,
>> if that happens at global init time, the program can just abort.
>
> C++ mutexes always have a delayed initialitation since the constructor
> is noexcept. So the semaphore behind the mutex which backs contention
> is created on synchonzation, which may fail.

Wtf are you rambling on about!

>
>> In POSIX, ..
>
> It doesn't matter what a specific operating system says about that,
> the standard should honour a failure in this case, even more if you
> have deferred initialization with C++ mutexes.
>
> Rest unread.
>

Am 17.09.2023 um 20:53 schrieb Chris M. Thomasson:
> On 9/17/2023 11:51 AM, Bonita Montero wrote:
>> Am 17.09.2023 um 20:49 schrieb Kaz Kylheku:
>>
>>> When mutexes fail, it is due to bugs in the application.  In that case,
>>> if that happens at global init time, the program can just abort.
>>
>> C++ mutexes always have a delayed initialitation since the constructor
>> is noexcept. So the semaphore behind the mutex which backs contention
>> is created on synchonzation, which may fail.
>
> Wtf are you rambling on about!

You alleged me to not understand futexes and you don't understand
that yourself. Ask yourself how a mutex handles contention so that
a thread sleeps while another is processing.

On 9/17/2023 11:52 AM, Bonita Montero wrote:
> Am 17.09.2023 um 20:50 schrieb Chris M. Thomasson:
>> On 9/17/2023 11:44 AM, Bonita Montero wrote:
>>> Am 17.09.2023 um 20:42 schrieb Chris M. Thomasson:
>>>
>>>> They depend on an atomic predicate in userspace. ..
>>>
>>> This is not really userspace if the page accesses are trapped to have
>>> a faster way inside the kernel.
>>>
>>
>> Huh? Futexes are designed to allow userspace to use them efficiently.
>
> You don't understand futexes.

Oh please! wow.

> If you have contention
> there's still a kernel-transition through a MMU trap.

A slow-path in a synchronization algorithm can cause it to choose to
wait in the kernel, that is fine. If nothing waited in the kernel when a
slow-path is encountered, then, well, that would be spin-waits, not
exactly ideal for userspace. Think about it. An adaptive mutex will spin
wait a couple of times _before_ it has to wait in the kernel. It uses
this spin waiting to try to avoid calling into the kernel.

Did you know that a mutex does not need to create any kernel resources
at all? It can be a single word, that uses futex when it needs to wait.

No. Bonita. You need to study up.

Am 17.09.2023 um 21:01 schrieb Chris M. Thomasson:

> A slow-path in a synchronization algorithm can cause it to choose to
> wait in the kernel, ...

Futexes are a substitute for a semaphore, which in turn is a part of
a mutex. There must be a way to get a thread sleeping when there's
contention. So there must be kernel-support of a futex.
If you say that everything on that futex happens in userspace this
does just mean that there's no explicit kernel call from userspace,
but the kernel-transition is done through a MMU-trap, wich is usually
faster on most CPUs than a explicit kernel call.

> No. Bonita. You need to study up.

I've read the paper, you didn't understand or you didn't read it.

On 2023-09-17, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 17.09.2023 um 20:25 schrieb Chris M. Thomasson:
>
>> Getting WAIT_FAILED means something really bad has hit the fan.
>> WAIT_ABANDONED is fine and can be handled, akin to EOWNERDEAD.
>> This is for inter-process robust sync.
>
> It's unspecified why this happens.
>
>> A futex does not need to create new kernel resources on demand.
>> They are already there.
>
> Read the Linux futex paper. The page which holds the futex is locked
> and there's a wating queue for contenders inside the kernel.

Locking a page is just a state change, not a resource allocation.

Waiting on wait queues doesn't require external resources; Linux wait
queue nodes are allocated and initialized on the stack. The enqueueing
and dequeueing is just pointer operations.

Wait queues themselves have to be allocated somewhere. The Linux futex
subsystem pre-allocated a big hash table containing queues. A futex
is hashed and then arbitrarily mapped to a queue which already exists.
The operation does not fail; there is no error checking or handling in
that code path at all. The futex hash allows unrelated futexes to map to
the same wait queue. That means that when a futex is woken up, tasks
waiting for a different futex may be woken as a side effect.

A page which holds a futex might be initially not present and have
to be swapped in. That's a resource allocation that can fail due to OOM.
However, that threat exists for any not-present page in an overcommitted
VM system; it's not a futex problem. You can malloc a block of memory,
get a non-null pointer, only to have it fail on access later.

--
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-17, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 17.09.2023 um 20:49 schrieb Kaz Kylheku:
>
>> When mutexes fail, it is due to bugs in the application. In that case,
>> if that happens at global init time, the program can just abort.
>
> C++ mutexes always have a delayed initialitation since the constructor
> is noexcept. So the semaphore behind the mutex which backs contention
> is created on synchonzation, which may fail.
>
>> In POSIX, ..
>
> It doesn't matter what a specific operating system says about that,

s/operating system/international standard for operating system family/

> Rest unread.

Aha; I think this is your approach to documentation also.

--
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 17.09.2023 um 21:20 schrieb Kaz Kylheku:

> Locking a page is just a state change, not a resource allocation.

That's a completely different discussion. The standard should not
be based on individual implementations, but should allow for the
possibility that the failure of synchronization or the synchroni-
zation itself fails. The standard also provides for this with a
std::mutex, why not for the initialization of statically local
objects ?

Rest unread.

On 2023-09-17, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 17.09.2023 um 21:20 schrieb Kaz Kylheku:
>
>> Locking a page is just a state change, not a resource allocation.
>
> That's a completely different discussion. The standard should not
> be based on individual implementations, but should allow for the
> possibility that the failure of synchronization or the synchroni-
> zation itself fails.

No it shouldn't. Synchronization that fails for reasons other than
a bug in the program (deadlock, unlocking un-owned mutex, recursively
acquiring non-recursive mutex, ...) is a wrongheaded idea, that should
not and need not be contemplated by any language or library standard
anywhere, ever.

Futexes are carefully designed not to require resource allocation
in futex_wait, in light of the above common understanding.

--
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/17/23 2:43 PM, Bonita Montero wrote:
> Am 17.09.2023 um 20:27 schrieb Chris M. Thomasson:
>> On 9/17/2023 11:06 AM, Bonita Montero wrote:
>>> Am 17.09.2023 um 19:37 schrieb Pavel:
>>>
>>>> Bonita Montero wrote:
>>>>> As I've shown with my program MSVC, libstdc++ (g++) and libc++
>>>>> (clang++)
>>>>> have per object mutexes.
>>>
>>>> No your program does not show this. ...
>>>
>>> Of course I show this. I've got a generic lambda and each thread
>>> gets its own instantiation of the calling operator of that lambda,
>>> thereby having _individual_ static objects per calling operator.
>>>
>>
>> Sigh.
>
> Here's the code again:
>
> #include <iostream>
> #include <utility>
> #include <vector>
> #include <thread>
>
> using namespace std;
>
> int main()
> {
>     struct InitSleep
>     {
>         InitSleep()
>         {
>             this_thread::sleep_for( 1s );
>         }
>     };
>     constexpr unsigned N_THREADS = 100;
>     auto unroll = []<size_t ... Indices>( index_sequence<Indices ...>,
> auto fn )
>     {
>         (fn.template operator ()<Indices>(), ...);
>     };
>     vector<jthread> threads;
>     threads.reserve( N_THREADS );
>     unroll( make_index_sequence<N_THREADS>(),
>         [&]<size_t T>()
>         {
>             threads.emplace_back( []( auto )
>                 {
>                     static InitSleep is;
>                 }, integral_constant<size_t, T>() );
>         } );
> }
>
> The calling operator of the theads's function object is generic
> and instantited once per T. So the static is object is individual
> per each instantiation of the calling operator. The above code
> takes about one second with MSVC, g++ (libstdc++) and clan++
> (libc++), so there's an individual mutex per calling operator
> of the above lambda.
> So if you handle it that way creating synchronization and the
> synchronization may fail. The standard shoud support appropriate
> error handling if initialization is done that fine grained like
> with the mentioned implementations.
>
>

Which just means that there is a path that, in this case, allows
parallel execution. Note, there are ways to handle this synchronization
that doesn't need holding a mutex per instance for the full time of the
constructor running.

Until you look at the code ACTUALLY GENERATED, you don't know how they
are doing it.

On 9/17/23 2:49 PM, Bonita Montero wrote:
> Am 17.09.2023 um 20:37 schrieb Richard Damon:
>
>> You haven't actually looked at HOW the code actually does what it
>> does, so you haven't shown anything (except your own limitations in
>> understanding code).
>
> I don't need to check that. I've proven that each static local
> object has its own initialization and not a shared mutex because
> the code runs exactly one second. So if you have an indivivual
> mutex per static local object this synchronization may fail.
> A pre-allocated global mutex for all static local initialization
> may not fail, but the standard should honour platforms where
> this actually can happen.
>

Nope, you shown that it can't be a single mutex held for the entire time
of the constructor.

So, you have defeated a Strawman, not proved your point.

Your logic is as bad as Olcott.