On 2023-09-18, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 17.09.2023 um 21:47 schrieb Richard Damon:
>
>> Why does it need to take into account that an BAD implementation might
>> fail.
>
> With the deferred initialization of a C++ mutex the mutex
> could fail on synchronization even without being bad.

Initialization of a mutex isn't synchronization.

You cannot defer a mutex's initialization until the point where it is
needed for synchronizing something; that is too late.

Well, you can do it, like any other object used for any other purpose,
but you will need another mutex to synchronize that initialization,
and that other mutex has to be already initialized.

Note that in POSIX, you can initialize a mutex with a static
initializer:

static pthread_mutex_t staticMutex = PTHREAD_MUTEX_INITIALIZER;

This does not fail.

For once-only, thread-safe initialization of static objects, an
implementation could use a hidden mutex which can very similarly be
statically initialized, like the POSIX one.

--
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 18.09.2023 um 19:30 schrieb Kaz Kylheku:

> It could be, but a C++ API that does not throw exceptions or return
> error indications wouldn't be able to express support for mutex
> debugging, ...

The constructor is noexcept, so the kernel-part of the mutex for the
slow path needs to be created deferred. This of course can fail and
has _nothing_ to do with mutex debugging.
The mutex which comes along with a static initialization needs to be
created when there's contention on the initialization; this also can
fail, so an exception would be appropriate, preferrably a system_error
as with mutex::lock() and ::unlock().

Am 18.09.2023 um 19:34 schrieb Kaz Kylheku:

> Initialization of a mutex isn't synchronization.

The constructor of mutex is noexept, so if there's contention and
a threads needs to wait it has to create the kernel-part for the
slow path inside lock(). There's no way to have that different
when the constructor is noexcept.

> You cannot defer a mutex's initialization until the point where
> it is needed for synchronizing something; that is too late.

Of course you can and you have to because the std::mutex's constructor
is noxcept. And if there's contention and a thread needs to wait it
creates the kernel sempahore, looks with a CAS if there's already one
created meanwhile and if not the seaphore is attached, otherwise the
own semaphore is destroyed and the mutex attached meanwhile by another
contender is used. The situation that there are multiple semaphores
created and only one is used while the others are destroyed is rather
unlikely, but it might happen.
There's no way to have that different since the construtor is noxcept.
The advantage of that is that some mutexes might be only uses with
their fast paths so never a kernel-semaphore is created so that the
mutex keeps rather lightweight.

On 2023-09-18, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Rest unread.

I'm afraid that's not very convicing, because the rest of your behavior
shows that you have a voracious appetite for responding to anything and
everything that you're able to.

--
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-18, Richard Damon <Richard@Damon-Family.org> wrote:
> On 9/18/23 1:18 AM, Bonita Montero wrote:
>> Am 17.09.2023 um 23:29 schrieb Paavo Helde:
>>
>>> Studying the actual code shows MSVC is using a critical section and
>>> libstc++ is using a futex. These are both single-process only
>>> facilities which cannot fail in ...
>>
>> Specific implementations don't matter because the point is that
>> C++ should honor implementations that can theoretically fail.
>>
>
> Why?
>
> Since it can be done without ever failing, why should the Standard allow
> for failure.

Just for debugging. Same reason why pthread_mutex_lock on POSIX returns int.

If you're sure your program is right, you don't use a debugging mutex
and don't check that int.

An exception would be better because that condition does not go
unchecked just because someone didn't bother.

If a hidden mutex is used for guarding a static initialization,
and static initialization can run arbitrary code (constructors that
can enter static blocks that contain more static initializations)
it is conceivable that the hidden mutexes could deadlock.

In that situation it would be useful if there was an exception or abort.

Just like in POSIX we can have a debugging mutex return EDEADLK.

I don't think that situation would ever be something the application
should handle with some try block, as part of the application logic.
It's something to debug and eliminate.

--
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 18.09.2023 um 19:53 schrieb Kaz Kylheku:

> I'm afraid that's not very convicing, because the rest of your behavior
> shows that you have a voracious appetite for responding to anything and
> everything that you're able to.

I just wanted to correct your wrong assumptions, and I did it well.

Am 18.09.2023 um 20:07 schrieb Kaz Kylheku:

> Just for debugging. Same reason why pthread_mutex_lock on POSIX returns int.

You won't catch that error while debugging since this could happen only
in situations with very little free memory. In such situations the sys-
tem is swapping and unusable. You won't manage to use a debugger .

> If you're sure your program is right, you don't use a debugging mutex
> and don't check that int.

I've got a function which is called exc_terminate, locking a mutex
is done like that: exc_terminate( [&]() { guard.lock(); } ). The
lock guard is therefore initialized for deferred locking.

> If a hidden mutex is used for guarding a static initialization,
> and static initialization can run arbitrary code (constructors that
> can enter static blocks that contain more static initializations)
> it is conceivable that the hidden mutexes could deadlock.

Local static objects are initialized when the code comes across the
initialization. All other static local objects it refers to have been
declared before, otherwise the static object wouldn't be able to use
them. So there will be never a deadlock.

On 2023-09-18, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 18.09.2023 um 19:53 schrieb Kaz Kylheku:
>
>> I'm afraid that's not very convicing, because the rest of your behavior
>> shows that you have a voracious appetite for responding to anything and
>> everything that you're able to.
>
> I just wanted to correct your wrong assumptions, and I did it well.

LOL, how well did that work in final exams?

"Dear Prof, you made a wrong assuption in Question 1 and, in my
mind, I responded to it well. I prudently refrained from reading
2 through 20, expecting them to be the same twaddle."

--
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/2023 10:05 PM, Bonita Montero wrote:
> Am 17.09.2023 um 21:57 schrieb Chris M. Thomasson:
>
>> I still don't think you know how they work.
>
> You didn't read the paper, not me.
>

I already know how futexes work. In and out.

On 9/17/2023 12:36 PM, Kaz Kylheku wrote:
> 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.
>

Agreed.

On 9/17/2023 10:07 PM, Bonita Montero wrote:
> Am 17.09.2023 um 21:47 schrieb Richard Damon:
>
>> Why does it need to take into account that an BAD implementation might
>> fail.
>
> With the deferred initialization of a C++ mutex the mutex
> could fail on synchronization even without being bad.

The impl must make sure to get it right wrt static initialization.

On 9/18/2023 10:43 AM, Bonita Montero wrote:
> Am 18.09.2023 um 19:34 schrieb Kaz Kylheku:
>
>> Initialization of a mutex isn't synchronization.
>
> The constructor of mutex is noexept, so if there's contention and
> a threads needs to wait it has to create the kernel-part for the
> slow path inside lock(). There's no way to have that different
> when the constructor is noexcept.

BARF!

>
>> You cannot defer a mutex's initialization until the point where
>> it is needed for synchronizing something; that is too late.
>
> Of course you can and you have to because the std::mutex's constructor
> is noxcept. And if there's contention and a thread needs to wait it
> creates the kernel sempahore, looks with a CAS if there's already one
> created meanwhile and if not the seaphore is attached, otherwise the
> own semaphore is destroyed and the mutex attached meanwhile by another
> contender is used. The situation that there are multiple semaphores
> created and only one is used while the others are destroyed is rather
> unlikely, but it might happen.
> There's no way to have that different since the construtor is noxcept.
> The advantage of that is that some mutexes might be only uses with
> their fast paths so never a kernel-semaphore is created so that the
> mutex keeps rather lightweight.
>
>

On 9/17/2023 10:16 PM, Bonita Montero wrote:
> Am 17.09.2023 um 21:49 schrieb Kaz Kylheku:
>
>> It's one that you started ...
>
> No, I didn't start it, Chris did. And at this point it was
> no longer a question of whether synchronization could fail.
>
> Rest unread.
>

I said that I have my doubts on your ability to understand futexes. You
have made some really strange false statements here. Sorry, is not my
fault when I detect them. Sorry, Bonita.

On 9/18/2023 11:15 AM, Kaz Kylheku wrote:
> On 2023-09-18, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 18.09.2023 um 19:53 schrieb Kaz Kylheku:
>>
>>> I'm afraid that's not very convicing, because the rest of your behavior
>>> shows that you have a voracious appetite for responding to anything and
>>> everything that you're able to.
>>
>> I just wanted to correct your wrong assumptions, and I did it well.
>
> LOL, how well did that work in final exams?
>
> "Dear Prof, you made a wrong assuption in Question 1 and, in my
> mind, I responded to it well. I prudently refrained from reading
> 2 through 20, expecting them to be the same twaddle."
>

Bonita, the beautiful Toll of Troll?

On 9/17/2023 10:09 PM, Bonita Montero wrote:
> Am 17.09.2023 um 22:23 schrieb Chris M. Thomasson:
>
>> I personally consider contention to be a so-called slow-path. ...
>
> The futex part is to make the slow path faster.
>

;^o

A futex is meant to handle a slow-path when a user algorithm finally
decides that it must block in the kernel. The futex can be thought of as
a nice, sort of, "condition variable" for algorithms. A fath-path can be
lock/wait-free indeed, however a futex gives them ability to actually
wait in the kernel.

A futex means that the user algorithm can use addresses based sync and
not have to worry about creating and destroying kernel resources. Its
not really about making the slow path "faster". Wrt the user algorithm,
a slow-path that must use the kernel is slow by default. We try to avoid
slow-paths. One simple way is that of an adaptive mutex.

I actually created a futex emulation that used wait queues, however...
It's all in userspace and thus can basically only honor SCHED_OTHER.

Btw, take a good look at the benaphore. Its a way to try to avoid calls
into the kernel. This is not using a futex, but a semaphore iirc:

https://www.haiku-os.org/legacy-docs/benewsletter/Issue1-26.html#Engineering1-26

A futex is a lot more flexible than this setup.

On 9/17/2023 12:22 PM, Kaz Kylheku wrote:
> 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.
>

Bonita might be morphing into troll mode again. Not just insult mode.

On 2023-09-18, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 18.09.2023 um 20:07 schrieb Kaz Kylheku:
>
>> Just for debugging. Same reason why pthread_mutex_lock on POSIX returns int.
>
> You won't catch that error while debugging since this could happen only

I've no idea what "that error" refers to.

> in situations with very little free memory. In such situations the sys-
> tem is swapping and unusable. You won't manage to use a debugger .

I'm not aware of any mutex-specific error that has to do with low
memory, and didn't mention one.

>> If a hidden mutex is used for guarding a static initialization,
>> and static initialization can run arbitrary code (constructors that
>> can enter static blocks that contain more static initializations)
>> it is conceivable that the hidden mutexes could deadlock.
>
> Local static objects are initialized when the code comes across the
> initialization. All other static local objects it refers to have been
> declared before, otherwise the static object wouldn't be able to use
> them. So there will be never a deadlock.

That is false:

struct static_thing
{
// constructor calls function pointer argument
static_thing(void (*)(pfn))
{
pfn();
}
};

void A(void)
{
static_thing o(B);
}

void B(void)
{
static_thing o(A);
}

Suppose A and B have not been called yet. We have two
threads, T1 and T2. T1 calls A() at around the same time
as T2 calls B().

T1 and T2 both lock the respective hidden mutexes that guard
the initialization of the two static objects. Let's call those
the "A mutex" and "B mutex".

While holding the A mutex, T1 then calls B() through the pointer,
and blocks on trying to acquire the B mutex. Reciprocally, T2 calls A
while holding the B mutex and blocks on the A mutex.

This is a classic deadlock due to opposite acquisition of the same
resources.

Since blocks with static initializations can be anywhere and
are entered by any thread in any order, and the constructor
calls can do it too, there is a threat.

(There will likely be a "double checked locking pattern" at play,
but that doesn't solve the deadlock. T1 will call B() where it
sees that the flag has not been set indicating that o has
been constructed, and so it will go through the slow path and
hit the mutex.)

--
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/2023 10:20 PM, Bonita Montero wrote:
> Am 17.09.2023 um 22:01 schrieb Pavel:
>
>> Of course you don't show that the synchronization primitives that are
>> used for static initialization are mutexes.
>
> Call it mutex or whatever: the standard requires that contenders
> sleep in place,

Huh?

> and that's only possible with something that works
> like a mutex.
>

wow... For some reason I just heard the sound of a toilet flushing. Over
your head?

On 9/17/2023 10:18 PM, Bonita Montero wrote:
> Am 17.09.2023 um 23:29 schrieb Paavo Helde:
>
>> Studying the actual code shows MSVC is using a critical section and
>> libstc++ is using a futex. These are both single-process only
>> facilities which cannot fail in ...
>
> Specific implementations don't matter because the point is that
> C++ should honor implementations that can theoretically fail.
>

Humm... Fail for what reasons? User? Humm...

On 9/18/2023 11:07 AM, Kaz Kylheku wrote:
> On 2023-09-18, Richard Damon <Richard@Damon-Family.org> wrote:
>> On 9/18/23 1:18 AM, Bonita Montero wrote:
>>> Am 17.09.2023 um 23:29 schrieb Paavo Helde:
>>>
>>>> Studying the actual code shows MSVC is using a critical section and
>>>> libstc++ is using a futex. These are both single-process only
>>>> facilities which cannot fail in ...
>>>
>>> Specific implementations don't matter because the point is that
>>> C++ should honor implementations that can theoretically fail.
>>>
>>
>> Why?
>>
>> Since it can be done without ever failing, why should the Standard allow
>> for failure.
>
> Just for debugging. Same reason why pthread_mutex_lock on POSIX returns int.
>
> If you're sure your program is right, you don't use a debugging mutex
> and don't check that int.
>
> An exception would be better because that condition does not go
> unchecked just because someone didn't bother.
>
> If a hidden mutex is used for guarding a static initialization,
> and static initialization can run arbitrary code (constructors that
> can enter static blocks that contain more static initializations)
> it is conceivable that the hidden mutexes could deadlock.

If a deadlock occurs wrt static initialization _itself_, well, that
should be the fault of the impl, yikes!. Although, if the user is not
that skilled, and makes the object that is being statically initialized
do something that makes itself deadlock in a ctor or something. Well,
that is on the user, not the impl....

Fair enough?

> In that situation it would be useful if there was an exception or abort.
>
> Just like in POSIX we can have a debugging mutex return EDEADLK.
>
> I don't think that situation would ever be something the application
> should handle with some try block, as part of the application logic.
> It's something to debug and eliminate.
>

Right. The impl shall get it right, (tm). Also, the other part of the
contract, is that the user should get it right as well. It kind of seems
like Bonita wants C/C++ to put proverbial "corks on the forks" for user
code:

A C/C++ impl should handle all, and think that its users are all somehow
akin to Ruprecht in the following scene:

https://youtu.be/SKDX-qJaJ08

Why is the cork on the fork... To prevent C and/or C++ from hurting
himself... ;^) lol.

On 9/18/2023 7:59 AM, Scott Lurndal wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 17.09.2023 um 23:29 schrieb Paavo Helde:
>>
>>> Studying the actual code shows MSVC is using a critical section and
>>> libstc++ is using a futex. These are both single-process only facilities
>>> which cannot fail in ...
>>
>> Specific implementations don't matter because the point is that
>> C++ should honor implementations that can theoretically fail.
>
> Feel free to submit a proposal to the C++ standard committee.
>
> Since everyone particpating in this discussion on comp.lang.c++
> seems to take the opposite view that you do, I don't believe you'll
> have much success in your proposal.

Bonita, is an interesting person, indeed.

On 9/18/2023 5:45 AM, Bonita Montero wrote:
> Am 18.09.2023 um 14:11 schrieb Richard Damon:
>
>> You are assuming is uses the object the OS is calling a "Mutex", which
>> is an object that works inter-process, but we don't need anything that
>> powerful.
>
> When I talk about a mutex in the context of C++, especially when
> it comes to static initialization, it should be clear that I don't
> mean mutexes that are "inter-process".
>
>> So, the alternative to using a Windows Mutex is using something else.
>> Something which can't fail.
>
> At least the creation of the kernel resource for the slow path of
> the mutex can fail. And under Windows even a WaitForSingleObject(),
> which usually is used for the slow path, can fail for not entirely
> specified reasons.

Huh?

>
> I had the same discussion on Stack Overflow and had the same objections,
> but lastly the people with these objections saw that what I was saying
> made sense. Here, however, there are only idiots.
>
> I don't know what the fuss is about: if waiting for a std::mutex
> can fail, the people who developed the standard figured that the
> operating system part could fail. Accordingly, there is an exception
> for std::mutex if you lock it. If you look at this consistently,
> static initialization should also be able to throw an exception
> for the same reason because the same kernel mechanisms are behind
> it.

On 9/18/2023 1:01 PM, Chris M. Thomasson wrote:
> On 9/18/2023 5:45 AM, Bonita Montero wrote:
>> Am 18.09.2023 um 14:11 schrieb Richard Damon:
>>
>>> You are assuming is uses the object the OS is calling a "Mutex",
>>> which is an object that works inter-process, but we don't need
>>> anything that powerful.
>>
>> When I talk about a mutex in the context of C++, especially when
>> it comes to static initialization, it should be clear that I don't
>> mean mutexes that are "inter-process".
>>
>>> So, the alternative to using a Windows Mutex is using something else.
>>> Something which can't fail.
>>
>> At least the creation of the kernel resource for the slow path of
>> the mutex can fail. And under Windows even a WaitForSingleObject(),
>> which usually is used for the slow path, can fail for not entirely
>> specified reasons.
>
> Huh?

An impl SHALL get static initialization right. Leave it up the to user
to deadlock everything. ;^o

>
>
>>
>> I had the same discussion on Stack Overflow and had the same objections,
>> but lastly the people with these objections saw that what I was saying
>> made sense. Here, however, there are only idiots.
>>
>> I don't know what the fuss is about: if waiting for a std::mutex
>> can fail, the people who developed the standard figured that the
>> operating system part could fail. Accordingly, there is an exception
>> for std::mutex if you lock it. If you look at this consistently,
>> static initialization should also be able to throw an exception
>> for the same reason because the same kernel mechanisms are behind
>> it.
>

Chris M. Thomasson wrote:
> On 9/11/2023 8:58 PM, Pavel wrote:
>> Chris M. Thomasson wrote:
>>> On 9/10/2023 3:50 PM, Pavel wrote:
>>>> Richard Damon wrote:
>>>>> On 9/10/23 1:57 AM, Bonita Montero wrote:
>>>>>> Am 09.09.2023 um 22:37 schrieb Richard Damon:
>>>>>>
>>>>>>> The Standard defines the final results that must happen
>>>>>>> (or possibilities that can happen in some cases).
>>>>>>
>>>>>> The standards also should consider side effects as in this example
>>>>>> when a static initialization would fail because of a synchronization
>>>>>> error.
>>>>>>
>>>>> You don't seem to understand that sincd it CAN be done in a way
>>>>> that always works, any method that doesn't always work is just
>>>>> WRONG and non-conforming.
>>>>>
>>>>> I guess you think that 1 + 1 must be allowed to be 1 in case of
>>>>> "synchronization errors".
>>>>>
>>>>> Static Initialization has DEFINED behavior, and that behavior must
>>>>> be honored, and the implementation do what is need to make that
>>>>> happen.
>>>>>
>>>>> Methods have been shown to do it (perhaps less performant than this
>>>>> is some conditions),
>>>> Actually, I think there should be always a better-performing method
>>>> to implement C++ static initialization than using windows or pthread
>>>> mutex -- e.g. using a specialized control like those used for
>>>> call_once implementation -- at least on UNIX or Windows.
>>>>
>>>> This is because IMHO mutex API is a textbook case of feature bloat
>>>> on both platforms.
>>>>
>>>> E.g. in standard UNIX (former POSIX), you can have recursive /
>>>> robust / shared / errorcheck mutex (not all mutually exclusive) and
>>>> who knows what else. pthread_mutex_lock shall be able to deal with
>>>> either combination and the feature-check code makes (at least the
>>>> current) implementation quite messy, with multiple dispatches on the
>>>> same condition.
>>>>
>>>> On Windows, the number of options is less; but, to compensate for
>>>> that :-), a mutex is always recursive plus wait functions have to
>>>> know how to deal with inter-process mutexes because any handle
>>>> passed to them can turn out to be of an inter-process mutex (or even
>>>> not a mutex at all). Therefore, I do not think their use for static
>>>> initialization (that does not require either recursive or
>>>> inter-process lock) even could be optimal.
>>>
>>> I might be missing your point here. Humm... Even though POSIX has all
>>> of these different types of mutexs, we can use them by organization.
>> The point is that, even assuming that all types of mutices are very
>> well organized in the implementation, some dispatch of control still
>> has to occur when one calls "pthread_mutex_lock" because it is a
>> single entry point for locking a mutex with any combination of
>> features. Given that locking of a non-contended mutex is supposed to
>> be (and in fact is, on current Linux) very cheap (but not necessarily
>> same-cheap if the mutex is recursive :-) ), the relative cost of this
>> dispatch is not guaranteed to be negligible (even if that dispatch is
>> implemented via a single extra level of indirection).
>>
>> Further, I am unsure if these features actually *can* be very well
>> organized because not all features of mutices are mutually exclusive
>> (no pun intended) so a single extra level of indirection might not be
>> enugh. As an example, mutexattr type can be one of
>>
>>   PTHREAD_MUTEX_NORMAL PTHREAD_MUTEX_ERRORCHECK
>> PTHREAD_MUTEX_RECURSIVE PTHREAD_MUTEX_DEFAULT
>
> Yeah. It's up to us programmers to make sure everything is right on our
> end. What about:
>
> intra_process_mutex_recursive m_mutex_recurive;

Agree, good names are important for readability.

The issue with POSIX mutex is that there is only one C type for all
mutex types, pthread_mutex_t so at least one dispatch is necessary (and,
at least in the current Linux implementation, many dispatches are done).

>
> I find that a more descriptive name can help wrt reading code created by
> somebody else. Humm... Actaly, I do not like to use recursive mutexes
> very much (if at all) because I have had to debug some other peoples
> "nightmare" code that recursed, and caused a deadlock around four locks
> deep.... It technically was not the fault of the recursion ability, but
> it was an error on the programmers side. The name of the lock was
> something like (object.m_lock), it was vague and I did not even know it
> recursed until I took a deeper look at the damn "nightmare" code. So,
> iirc, I said out loud, name it something else... How about:
>
> object.m_lock_recusive__never__use__
>
> and got a laugh from the room. :^)
>
>
>
>
>
>>
>> but each of these can be additionally either robust or non-robust
>> (and, pthread_mutex_lock is supposed to behave differently for some
>> combinations of type and robustness). Unless of course we dispatch to
>> a cartesian product of options (which is not impossible, but see below).
>>
>> And, lastly, the above are all hypotheticals and the actual code (see
>> e.g.
>> https://codebrowser.dev/glibc/glibc/nptl/pthread_mutex_lock.c.html )
>> is slightly messier than the best organized implementation possible.
>>  From practical perspective, I would expect that someone implementing
>> a thread-safe static initialization in a C++ compiler has their mouth
>> full with the tasks other than improving the existing pthread_mutex
>> (or pthread_once) implementation as a distraction; at most (I would
>> speculate), they would take a quick (~5 min) look into the API and the
>> available code of the existing established synchronization primitives
>> and decide which one is likely to better fit their spec and be faster
>> as-is to use to implement that pesky initialization spec. In this
>> scenario, I would guess that pthread_once_t would win the beauty
>> contest and get selected.
>>
>> And, sure enough, (likely due to no feature bloat) the *existing*
>> pthread_once implementation code is much cleaner (see
>> https://codebrowser.dev/glibc/glibc/nptl/pthread_once.c.html) and at
>> first glance should be measurably faster.
>>
>> I guess, instead of guessing, (no pun untended again), we could just
>> disassemble some static initialization and see how it's done in, say,
>> gcc. Maybe later...
>>
>>> So, wrt windows, an intra-process mutex can be a CRITICAL_SECTION. Or
>>> an inter-process as a mutex HANDLE.
>>>
>>> https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createmutexexa
>>>
>>>
>>> Wrt the inter-process route we may need to deal with WAIT_ABANDONED,
>>> or EOWNERDEAD wrt POSIX. So we create different types:
>>>
>>>
>>> struct intra_process_mutex
>>> {
>>>      CRITICAL_SECTION m_os_lock;
>>> };
>>>
>>>
>>> struct inter_process_mutex
>>> {
>>>      HANDLE m_os_lock;
>>> };
>>>
>>> struct inter_process_mutex_robust
>>> {
>>>      HANDLE m_os_lock;
>>> };
>>>
>>>
>>>
>>> These simple types can be rather easy to reason about. Wrt POSIX, the
>>> different types would be:
>>>
>>>
>>> struct intra_process_mutex
>>> {
>>>      pthread_mutex_t m_os_lock;
>>> };
>>>
>>>
>>> struct inter_process_mutex
>>> {
>>>      pthread_mutex_t m_os_lock;
>>> };
>>>
>>> struct inter_process_mutex_robust
>>> {
>>>      pthread_mutex_t m_os_lock;
>>> };
>>>
>>>
>>> The point is trying to organize things a bit here.
>>>
>>> Sound somewhat decent?
>>>
>>>
>>>>
>>>>> so it is possible, so you can't say the Standard is asking for
>>>>> impossible behavior, thus any "optimizations" that don't meet that
>>>>> defined behavior are just WRONG.
>>>>>
>>>>> Saying something wrong must be made right is just WRONG, so you are
>>>>> WRONG in your claim.
>>>>>
>>>>> PERIOD.
>>>>
>>>
>>
>

Bonita Montero wrote:
> Am 18.09.2023 um 19:30 schrieb Kaz Kylheku:
>
>> It could be, but a C++ API that does not throw exceptions or return
>> error indications wouldn't be able to express support for mutex
>> debugging, ...
>
> The constructor is noexcept, so the kernel-part of the mutex for the
> slow path needs to be created deferred.
Or, when there is nothing to create, there is nothing to defer,

> This of course can fail
and, of course, nothing can fail.

> and
> has _nothing_ to do with mutex debugging.
> The mutex which comes along with a static initialization needs to be
> created when there's contention on the initialization; this also can
> fail, so an exception would be appropriate, preferrably a system_error
> as with mutex::lock() and ::unlock().
>
>