Am 25.09.2023 um 13:15 schrieb Richard Damon:

> You argument is basically, the Standard needs to allow for BAD
> implementation to exist.

And implementation that throws in this situation isn't bad for me.

Am 25.09.2023 um 17:51 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:

>> lock() and unlock() might throw system_error.

> lock() and unlock() cannot throw any error.

https://en.cppreference.com/w/cpp/thread/mutex/lock

"Throws std::system_error when errors occur, including errors
from the underlying operating system that would prevent lock
from meeting its specifications. The mutex is not locked in
the case of any exception being thrown."

https://en.cppreference.com/w/cpp/thread/mutex/unlock

"Throws nothing"

You're right only in the latter case.

On Sunday, September 24, 2023 at 9:41:29 PM UTC+3, Chris M. Thomasson wrote:
> On 9/24/2023 2:50 AM, Michael S wrote:
> > On Sunday, September 24, 2023 at 11:09:31 AM UTC+3, Bonita Montero wrote:
> >> Am 24.09.2023 um 05:05 schrieb Chris M. Thomasson:
> >>
> >>> Why do you think that static initialization must use a std::mutex
> >>> anyway? ...
> >>
> >> Call it std::mutex or whatever. It is mandated that contenders
> >> are sleeping - that's not possible without sth. else than a mutex.
> >
> > Few dozens posts above I demonstrated an implementation
> > for pre-Vista Windows where contenders are sleeping just fine and
> > waking just fine and initialization of different objects proceeds
> > simultaneously just fine. And it does not use mutex for that.
> > It uses SleepEx() for wait and QueueUserApc() for wakeup.
>
> Why? APC's open up a big can of worms.
>

Because for pre-Vista I can't think about better solution.
https://groups.google.com/g/comp.lang.c++/c/bTiLC2zWR4M/m/XG1aWCEDAAAJ
And frankly I see no worms.

>
> > It uses one global mutex (in form of critical section) for a short
> > while for metadata updates, but that's done for simplicity and
> > practicality rather than out of necessity. I am pretty sure that
> > with enough effort I can device a variant that achieves the same
> > with CaS.

On Sunday, September 24, 2023 at 9:49:44 PM UTC+3, Chris M. Thomasson wrote:
> On 9/24/2023 11:41 AM, Chris M. Thomasson wrote:
> > On 9/24/2023 2:50 AM, Michael S wrote:
> >> On Sunday, September 24, 2023 at 11:09:31 AM UTC+3, Bonita Montero wrote:
> >>> Am 24.09.2023 um 05:05 schrieb Chris M. Thomasson:
> >>>
> >>>> Why do you think that static initialization must use a std::mutex
> >>>> anyway? ...
> >>>
> >>> Call it std::mutex or whatever. It is mandated that contenders
> >>> are sleeping - that's not possible without sth. else than a mutex.
> >>
> >> Few dozens posts above I demonstrated an implementation
> >> for pre-Vista Windows where contenders are sleeping just fine and
> >> waking just fine and initialization of different objects proceeds
> >> simultaneously just fine. And it does not use mutex for that.
> >> It uses SleepEx() for wait and QueueUserApc() for wakeup.
> >
> > Why? APC's open up a big can of worms.
> Oh shit. I am starting to remember some nightmare code I had to debug
> many moon ago that used async cancellation in POSIX threads.
> >
> >

But Windows User APC, at least pre Win11, is async only on issue
side. On reception side it is fully synchronous and easy to reason about.
At least it is easy as long as you don't try to enter alertable wait
within APC routine, which I don't do. In fact, my APC routine is Nop.

> >> It uses one global mutex (in form of critical section) for a short
> >> while for metadata updates, but that's done for simplicity and
> >> practicality rather than out of necessity. I am pretty sure that
> >> with enough effort I can device a variant that achieves the same
> >> with CaS.
> >
> >

On 9/25/2023 9:11 AM, Bonita Montero wrote:
> Am 25.09.2023 um 13:15 schrieb Richard Damon:
>
>> You argument is basically, the Standard needs to allow for BAD
>> implementation to exist.
>
> And implementation that throws in this situation isn't bad for me.

Why? We are talking about intra-process sync here. Now, inter-process is
a completely different story...

On 9/25/2023 10:15 AM, Michael S wrote:
> On Sunday, September 24, 2023 at 9:41:29 PM UTC+3, Chris M. Thomasson wrote:
>> On 9/24/2023 2:50 AM, Michael S wrote:
>>> On Sunday, September 24, 2023 at 11:09:31 AM UTC+3, Bonita Montero wrote:
>>>> Am 24.09.2023 um 05:05 schrieb Chris M. Thomasson:
>>>>
>>>>> Why do you think that static initialization must use a std::mutex
>>>>> anyway? ...
>>>>
>>>> Call it std::mutex or whatever. It is mandated that contenders
>>>> are sleeping - that's not possible without sth. else than a mutex.
>>>
>>> Few dozens posts above I demonstrated an implementation
>>> for pre-Vista Windows where contenders are sleeping just fine and
>>> waking just fine and initialization of different objects proceeds
>>> simultaneously just fine. And it does not use mutex for that.
>>> It uses SleepEx() for wait and QueueUserApc() for wakeup.
>>
>> Why? APC's open up a big can of worms.
>>
>
> Because for pre-Vista I can't think about better solution.
> https://groups.google.com/g/comp.lang.c++/c/bTiLC2zWR4M/m/XG1aWCEDAAAJ
> And frankly I see no worms.

If you know how to properly use APC's, then you should be alright.

>
>>
>>> It uses one global mutex (in form of critical section) for a short
>>> while for metadata updates, but that's done for simplicity and
>>> practicality rather than out of necessity. I am pretty sure that
>>> with enough effort I can device a variant that achieves the same
>>> with CaS.

On 9/25/2023 4:15 AM, Richard Damon wrote:
> On 9/25/23 4:00 AM, Bonita Montero wrote:
>> Am 25.09.2023 um 03:15 schrieb Richard Damon:
>>
>>> Not for pthreads, ...
>>
>> The standard honors plattforms where an error may arise,
>> so it should also do that for static initialization.
>>
>
> So, you admit you lied when you said the problem you claimed applied to
> ALL operating systems.
>
> The reason the Standard allows Mutex lock to throw the error is because
> in some cases you might get an error, normally in response to a
> programmer error.
>
> The Standard just doesn't allow the implementation to use a Mutex in
> those error conditions for initialization syncronization.
>
> Again, you are showing your ignorance by insisting that the Standard
> give leniency to the implementation to allow it to do things wrong.

Basically, you are correct here.

On 9/25/2023 10:15 AM, Michael S wrote:
> On Sunday, September 24, 2023 at 9:41:29 PM UTC+3, Chris M. Thomasson wrote:
>> On 9/24/2023 2:50 AM, Michael S wrote:
>>> On Sunday, September 24, 2023 at 11:09:31 AM UTC+3, Bonita Montero wrote:
>>>> Am 24.09.2023 um 05:05 schrieb Chris M. Thomasson:
>>>>
>>>>> Why do you think that static initialization must use a std::mutex
>>>>> anyway? ...
>>>>
>>>> Call it std::mutex or whatever. It is mandated that contenders
>>>> are sleeping - that's not possible without sth. else than a mutex.
>>>
>>> Few dozens posts above I demonstrated an implementation
>>> for pre-Vista Windows where contenders are sleeping just fine and
>>> waking just fine and initialization of different objects proceeds
>>> simultaneously just fine. And it does not use mutex for that.
>>> It uses SleepEx() for wait and QueueUserApc() for wakeup.
>>
>> Why? APC's open up a big can of worms.
>>
>
> Because for pre-Vista I can't think about better solution.
> https://groups.google.com/g/comp.lang.c++/c/bTiLC2zWR4M/m/XG1aWCEDAAAJ
> And frankly I see no worms.
>
>>
>>> It uses one global mutex (in form of critical section) for a short
>>> while for metadata updates, but that's done for simplicity and
>>> practicality rather than out of necessity. I am pretty sure that
>>> with enough effort I can device a variant that achieves the same
>>> with CaS.

I don't think Relacy can model APC's in its current form, however it can
model a fairly decent number of Windows sync calls. When you get some
free time to burn, check it out! :^) Give it a go, for fun, when you
have nothing to do:

https://github.com/dvyukov/relacy

:^)

On 2023-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 25.09.2023 um 13:15 schrieb Richard Damon:
>
>> You argument is basically, the Standard needs to allow for BAD
>> implementation to exist.
>
> And implementation that throws in this situation isn't bad for me.

An implementation that throws in mutex locks that aren't process-shared
robust mutexes or anything of that sort is a ... sick joke.

--
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/9/2023 10:44 AM, Pavel wrote:
> Chris M. Thomasson wrote:
>> On 9/8/2023 5:14 PM, Pavel wrote:
>>> Chris M. Thomasson wrote:
>>>> On 9/7/2023 1:00 PM, Bonita Montero wrote:
>>>>> Am 07.09.2023 um 21:41 schrieb Chris M. Thomasson:
>>>>>
>>>>>> Yup. It uses address based hashing into the fixed mutex table.
>>>>>
>>>>> I guess that's not used at all in the runtimes.
>>>>>
>>>>
>>>> Why not?
>>>
>>> I think it's not needed in general for static initialization purpose.
>>>
>>> This is because, if our design choice for our "C++ compiler" is to
>>> use a dedicated mutex (or once_flag control) per a static variable
>>> that requires dynamic initialization, nothing prevents our compiler
>>> from allocating a static instance of such mutex or control next to
>>> the static variable.
>>>
>>> Because mutex and once_flag can be constant-initialized (at least in
>>> POSIX, notably Linux), the code that dynamically initializes a
>>> variable can directly use the address of its respective
>>> constant-initialized mutex or control, as in the following example:
>>>
>>> code in C++ source file:
>>>
>>> static type1 var1 = InitVar1();
>>>
>>> **pseudo-code** actually generated by the compiler:
>>>
>>> pthread_once_t __var1_once_control = PTHREAD_ONCE_INIT; /* generated
>>> by the compiler when  */
>>>
>>> static type1 var1 = InitVar1(); /* this is compiled to,
>>> **in pseudo-code**, to something like
>>>
>>>   pthread_once( [&var1]() { var1 = InitVar1(); } );
>>> */
>>
>> pthread_once is perfectly fine. Just wondering, are you creating the
>> POSIX impl directly here?
> I am not creating, just demonstrating in pseudo-code how Linux
> implementation could work.
>

That is perfectly fine. Thanks, Pavel. :^)

On 9/25/23 12:11 PM, Bonita Montero wrote:
> Am 25.09.2023 um 13:15 schrieb Richard Damon:
>
>> You argument is basically, the Standard needs to allow for BAD
>> implementation to exist.
>
> And implementation that throws in this situation isn't bad for me.

So, you don't mind you code not working as promised.

I guess you don't have to write code that actually works.

On 9/25/23 8:43 AM, Bonita Montero wrote:
> Am 25.09.2023 um 13:15 schrieb Richard Damon:
>
>> So, you admit you lied when you said the problem you claimed applied
>> to ALL operating systems.
>
> I never said that.

LIE

Question:
>> Name one platform for which it is not guaranteed and that targets a
compliant C++11+ implementation.

You Answer

>Any platform since lock() and unlock() might throw system_error()
as documented.

So the platfor for which you claim has the problem, is "Any Platform",
amd thus ALL platforms.

Either that, you your statement is just a deception and thus also a lie.

>
>> The reason the Standard allows Mutex lock to throw the error is
>> because  in some cases you might get an error, normally in response
>> to a programmer error.
>
> You don't know that.

no, YOU don't know what you are talking about, since you just prove you
are a liar.

Bonita Montero wrote:
> Am 24.09.2023 um 19:10 schrieb Pavel:
>
>> so? everyone has been telling you initialization of simple mutices
>> does  not fail. After few hundred posts, you decided to agree?
>
> lock() and unlock() might throw system_error.
>
>
On *some* C++ mutex the lock() method might throw. This does not matter
because such C++ mutex:

a. does not have to be used for C++ static initialization; and
b. is not the best solution for C++ static initialization (in
particular, not the best-performing solution); and
c. is not in fact used for C++ static initialization on common platforms
we could check.

Therefore, it is not necessary to change the C++ standard and allow
static initialization to throw.

Bonita Montero wrote:
> Am 24.09.2023 um 18:47 schrieb Pavel:
>> Bonita Montero wrote:
>
>> Name one platform for which it is not guaranteed and that targets a
>> compliant C++11+ implementation.
>
> Any platform since lock() and unlock() might throw system_error()
> as documented.
>
This does not matter as long as C++ static initialization can be
implemented as specified.

Bonita Montero wrote:
> Am 25.09.2023 um 03:15 schrieb Richard Damon:
>
>> Not for pthreads, ...
>
> The standard honors plattforms where an error may arise,
> so it should also do that for static initialization.
>
The standard does not honor platforms, it's the C++ implementation on a
platform might or might not honor the standard.

On 9/25/2023 5:43 AM, Bonita Montero wrote:
> Am 25.09.2023 um 13:15 schrieb Richard Damon:
>
>> So, you admit you lied when you said the problem you claimed applied
>> to ALL operating systems.
>
> I never said that.

Oh, that is rather rich!!! Yikes!

>
>> The reason the Standard allows Mutex lock to throw the error is
>> because  in some cases you might get an error, normally in response
>> to a programmer error.
>
> You don't know that.

On 9/25/2023 6:53 PM, Pavel wrote:
> Bonita Montero wrote:
>> Am 25.09.2023 um 03:15 schrieb Richard Damon:
>>
>>> Not for pthreads, ...
>>
>> The standard honors plattforms where an error may arise,
>> so it should also do that for static initialization.
>>
> The standard does not honor platforms, it's the C++ implementation on a
> platform might or might not honor the standard.

Ding! You got it, Pavel. :^)

Let's say I have a new experimental system that I want to be able to
work with POSIX. Therefore, I need to create all of the necessary
machinery to make it a reality, so to speak. I even have to create a
special C compiler for my new system to help things move along... This
would be the work that I have to put into gaining an actual
implementation that adheres to POSIX and C while providing all of the
required APIs...

I need to make damn sure that they all work according to POSIX. If I
want to create a C++/C 11 impl, I can perhaps even use the POSIX port
for it. You never know. ;^)

I think this aligns okay with your main point, Pavel?

:^)

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.

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.

Not in a correct program which is free of misuses of locks!

Misuses like: deadlocks; unlocking locks not owned by caller; using
locks which have not yet been initialized, or have been destroyed or are
corrupt.

If you're getting a system_error from a mutex operation, you should
debug that. Trying to recover from such a thing and continue is going to
be a giant hack.

Catching exceptions that are bugs is hostile to debugging with other
techniques; C++ exceptions unwind, which throws away information about
what went wrong where.

--
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/24/2023 10:04 AM, Kaz Kylheku wrote:
> On 2023-09-24, Bonita Montero <Bonita.Montero@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.

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

On 9/25/2023 10:52 PM, Chris M. Thomasson wrote:
> On 9/24/2023 10:04 AM, Kaz Kylheku wrote:
>> On 2023-09-24, Bonita Montero <Bonita.Montero@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.

The idea is that the "fast" part of the mutex allows threads to access
shared data without using any memory barriers, "usually" read only...
The "slow" part of the async mutex checks some things, reports its
intent then issues a FlushProcessWriteBuffers to sync up with the fast
part. This is basically akin to RCU, in a sense. Have you experimented
with the rather "exotic" async mutexes before? RCU is geared toward
giving reads full speed ahead captain, and writers are sort of second
class citizens. So, it's also async in a way...

There is a way to use FlushProcessWriteBuffers to create a "quiescent"
state, ala RCU, wrt memory visibility.

There is an interesting paper that described a technique, iirc, its
called QPI or something. That tried to "abuse" an x86 to generate remote
memory barriers. Iirc, they intentionally use unaligned accesses to
trigger a BUS lock. I need to find that damn paper! :^) I read it
before! damn it.

Thanks for sparking my mind on this. It's been a while Kaz. :^)

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

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.

On 9/26/23 12:36 AM, Bonita Montero 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.
>
>

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.

Is your problem that you, yourself, don't know how to do it, and you
think the Standard needs to degrade the promises given to allow for your
"broken" methods to be used?

WHy don't you understand that, at least for here, failure is not an
option, and no failure is achievable.

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.

Thus, doing something that might fail is just wrong.

You seem to like failing at what you try to do.