On 9/29/2023 12:37 PM, Bonita Montero wrote:
> Am 29.09.2023 um 21:34 schrieb Chris M. Thomasson:
>
>> Huh? Run your code through a race detector and we can go from there.
>> You want me to try to find a bug in the code you posted? Well, pay me.
>
> Idiot !

Oh yeah. I am going to do work for you. At least give it a go wrt a race
detector, then we can see some interesting things. Of course I can read
your code and do it by myself, but, its going to cost you.

Am 29.09.2023 um 21:38 schrieb Chris M. Thomasson:

> Say, a race detector finds a race condition in your code. You examine it
> and can _prove_ that it works, well, then the race detector was wrong.
> We can now dive into it.

Mutexes or the shared mutex I wrote always have race conditions
and that's not a problem.

On 9/29/2023 12:36 PM, Chris M. Thomasson wrote:
> On 9/29/2023 12:30 PM, Bonita Montero wrote:
>> Am 29.09.2023 um 21:26 schrieb Chris M. Thomasson:
>>
>>> Run it through a race detector, make sure it works.
>>
>> Your only answer to any MT-code that overburdens you is:
>> use a race detector.
>>
>
> Huh? Lets make sure it passes some tests, then we can dig into it. There
> could be a false negative.

negative, in the sense of a failed test.

I don't think you like to test any of your
> own code. Just throwing some example runs at it is not enough.

On 9/29/2023 12:43 PM, Bonita Montero wrote:
> Am 29.09.2023 um 21:38 schrieb Chris M. Thomasson:
>
>> Say, a race detector finds a race condition in your code. You examine
>> it and can _prove_ that it works, well, then the race detector was
>> wrong. We can now dive into it.
>
> Mutexes or the shared mutex I wrote always have race conditions
> and that's not a problem.

Huh? The code you write always has race conditions? Huh?

Oh my. You, well, shit. This is a troll!!! Has to be?

;^o

Am 29.09.2023 um 22:09 schrieb Chris M. Thomasson:

> Huh? The code you write always has race conditions? Huh?

Theres a random factor which determines who acquires a mutex first.
So this is a true race condition. So a race condtition can be totally
acceptable inside a mutex, but not outside a mutes with the code that
uses the mutex.

On 9/29/2023 1:14 PM, Bonita Montero wrote:
> Am 29.09.2023 um 22:09 schrieb Chris M. Thomasson:
>
>> Huh? The code you write always has race conditions? Huh?
>
> Theres a random factor which determines who acquires a mutex first.
> So this is a true race condition.

Oh god, please! That is a massive red herring.

> So a race condtition can be totally
> acceptable inside a mutex, but not outside a mutes with the code that
> uses the mutex.
>

Moronic word salad. For fun, check this out:

https://groups.google.com/g/comp.lang.c++/c/7u_rLgQe86k/m/fYU9SnuAFQAJ

;^)

A race condition can make things give erroneous results, can lead to
deadlock, can do a bunch of terrible things. The worst type of race
condition tends to be memory barrier based. The atomic rmw's are working
an in place, but the memory visibility is all screwed to hell and back.
So, the system might appear to be working fine, but will fuck up over time.

Who gets to lock first is a wild red herring. I don't think you know
what a race condition actually is.

On 9/6/2023 11:15 AM, Bonita Montero wrote:
[...]

I am going to refrain from talking to you for a while. Sorry, but you
simply must be trolling.

On 2023-09-29, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 29.09.2023 um 22:09 schrieb Chris M. Thomasson:
>
>> Huh? The code you write always has race conditions? Huh?
>
> Theres a random factor which determines who acquires a mutex first.
> So this is a true race condition. So a race condtition can be totally
> acceptable inside a mutex, but not outside a mutes with the code that
> uses the mutex.

The concept of a race condition is broad; it spans beyond software.

A race condition is a situation in which the system's behavior being
correct or incorrect depends on the incidental order of events between
unrelated event streams.

The system design assumes, for its correctness, that a certain event X
happens before Y, but this is not ensured and sometimes doesn't happen
because X and Y come from different event sources/streams which are not
synchronized.

In software, if we have divided the execution of a program into multiple
scheduling contexts, like threads, it's possible that the program will
arrive at its result via different execution orders. If for all
execution orders, the result is correct, then there is no race
condition.

Your mutex-based program may exhibit different execution orders.

There is no race condition unless some of the execution orders produce
an incorrect result.

Unfortunately, we cannot speak about correctness without referring to
the specification of the individual program. Correctness is not
absolute.

Suppose we have a specification "write a program that prints all the
integers in the range 1 to 10, on a separate linee". We can have the
program launch ten threads, give each of the threads one of those
integers as an argument. Each thread prints the argument and
terminates.

If we see an output like, this it is correct:

7
3 1
6 9
8 4
5 2
10

(Assume that we never see bad character interleaving; the I/O library
takes care of that.)

Now suppose we change the requirements that the integers have to be
presented in increasing order.

Then the same program is no longer correct, and we can identify it as
having race conditions.

It starts the 1-10 threads in order, but they don't issue their output
in that order.

The program hasn't change at all, only the specification of what is
correct, and that causes the program to have a race condition.

We agree that there are always perturbations in execution order
regardless of how correcntess is defined: the program does what it does.

A perturbation in execution order isn't a race; only when it
makes the program incorrect w.r.t it specification.

--
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 29.09.2023 um 22:30 schrieb Chris M. Thomasson:

> I am going to refrain from talking to you for a while. Sorry, but you
> simply must be trolling.

You never deal with the source you read here, but always come up with
the answer: use a race detector. That's trolling !

Bonita Montero wrote:
> Am 29.09.2023 um 03:46 schrieb Pavel:
>
>> see my or Kaz's explanation for how it is done without allocating any
>> kernel resource on either initialization or locking, either fast or
>> slow path.
>
> ... on Linux with signals.
>
With user-space sync primitives on any system.

Am 30.09.2023 um 05:57 schrieb Pavel:
> Bonita Montero wrote:
>> Am 29.09.2023 um 03:46 schrieb Pavel:
>>
>>> see my or Kaz's explanation for how it is done without allocating any
>>> kernel resource on either initialization or locking, either fast or
>>> slow path.
>>
>> ... on Linux with signals.
>>
> With user-space sync primitives on any system.

A mutex may lead to a sleeping thread, that's only possible with
the help of the kernel.

Am 29.09.2023 um 22:44 schrieb Kaz Kylheku:

> The concept of a race condition is broad; it spans beyond software.

And a race condition isn't always a problem. If there are different
outcoomes of a race condition either outcome may be acceptable if
the outcome has consistent data.

On 2023-09-30, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 29.09.2023 um 22:44 schrieb Kaz Kylheku:
>
>> The concept of a race condition is broad; it spans beyond software.
>
> And a race condition isn't always a problem.

As I explained, "race condition" is the name of a problem by definition.

Perturbed execution order, with externally visible differences in
behavior, is not always a problem.

> If there are different
> outcoomes of a race condition either outcome may be acceptable if
> the outcome has consistent data.

I.e. you forgot "Rest unread".

Am 30.09.2023 um 17:51 schrieb Kaz Kylheku:

> I.e. you forgot "Rest unread".

You get lost in unimportant details, not me.

On 2023-09-30, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 30.09.2023 um 17:51 schrieb Kaz Kylheku:
>
>> I.e. you forgot "Rest unread".
>
> You get lost in unimportant details, not me.

It's fairly important not to call perturbed execution orders
in a correct program "race conditions" because it communicates
not knowing the subject matter.

--
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 30.09.2023 um 19:05 schrieb Kaz Kylheku:

> On 2023-09-30, Bonita Montero <Bonita.Montero@gmail.com> wrote:

>> You get lost in unimportant details, not me.

> It's fairly important not to call perturbed execution orders
> in a correct program "race conditions" because it communicates
> not knowing the subject matter.

I mean: unimportant at this place, but not generally.

Bonita Montero wrote:
> Am 30.09.2023 um 05:57 schrieb Pavel:
>> Bonita Montero wrote:
>>> Am 29.09.2023 um 03:46 schrieb Pavel:
>>>
>>>> see my or Kaz's explanation for how it is done without allocating
>>>> any kernel resource on either initialization or locking, either fast
>>>> or slow path.
>>>
>>> ... on Linux with signals.
>>>
>> With user-space sync primitives on any system.
>
> A mutex may lead to a sleeping thread, that's only possible with
> the help of the kernel.

This does not prove that the kernel call to acquire the primitive may
fail. You made a more specific statement that the kernel had to allocate
resources on either initialization or locking and that could fail. And
that your statement was incorrect: the kernel does not have to allocate
resources, it may simply need to relink the thread from runqueue to the
user-space primitives's waiting list. This cannot fail. And hence the
C++ static variable initialization does not have to throw for
synchronization reasons. No need to change the standard.

On 9/30/23 1:26 PM, Bonita Montero wrote:
> Am 30.09.2023 um 19:05 schrieb Kaz Kylheku:
>
>> On 2023-09-30, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>
>>> You get lost in unimportant details, not me.
>
>> It's fairly important not to call perturbed execution orders
>> in a correct program "race conditions" because it communicates
>> not knowing the subject matter.
>
> I mean: unimportant at this place, but not generally.
>
>

When is it EVER "unimportant" that you are using incorrect terminology.

On 2023-09-30, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 30.09.2023 um 05:57 schrieb Pavel:
>> Bonita Montero wrote:
>>> Am 29.09.2023 um 03:46 schrieb Pavel:
>>>
>>>> see my or Kaz's explanation for how it is done without allocating any
>>>> kernel resource on either initialization or locking, either fast or
>>>> slow path.
>>>
>>> ... on Linux with signals.
>>>
>> With user-space sync primitives on any system.
>
> A mutex may lead to a sleeping thread, that's only possible with
> the help of the kernel.

You keep returning to this in circles, forgetting that the argument
isn't that help from the kernel isn't required.

The argument is that there is no need to allocate a kernel
object per mutex. That is only one point in the design space,
and not a very good one.

Do *you* have ADHD is the question.

--
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-30, Richard Damon <Richard@Damon-Family.org> wrote:
> On 9/30/23 1:26 PM, Bonita Montero wrote:
>> Am 30.09.2023 um 19:05 schrieb Kaz Kylheku:
>>
>>> On 2023-09-30, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>
>>>> You get lost in unimportant details, not me.
>>
>>> It's fairly important not to call perturbed execution orders
>>> in a correct program "race conditions" because it communicates
>>> not knowing the subject matter.
>>
>> I mean: unimportant at this place, but not generally.
>>
>>
>
> When is it EVER "unimportant" that you are using incorrect terminology.

When you're trolling under a pseudonym.

That is unmistakably what "unimportant in this place" means.

--
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/30/2023 10:05 AM, Kaz Kylheku wrote:
> On 2023-09-30, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 30.09.2023 um 17:51 schrieb Kaz Kylheku:
>>
>>> I.e. you forgot "Rest unread".
>>
>> You get lost in unimportant details, not me.
>
> It's fairly important not to call perturbed execution orders
> in a correct program "race conditions" because it communicates
> not knowing the subject matter.
>

Yup. Exactly.

On 9/30/2023 12:07 PM, Kaz Kylheku wrote:
> On 2023-09-30, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 30.09.2023 um 05:57 schrieb Pavel:
>>> Bonita Montero wrote:
>>>> Am 29.09.2023 um 03:46 schrieb Pavel:
>>>>
>>>>> see my or Kaz's explanation for how it is done without allocating any
>>>>> kernel resource on either initialization or locking, either fast or
>>>>> slow path.
>>>>
>>>> ... on Linux with signals.
>>>>
>>> With user-space sync primitives on any system.
>>
>> A mutex may lead to a sleeping thread, that's only possible with
>> the help of the kernel.
>
> You keep returning to this in circles, forgetting that the argument
> isn't that help from the kernel isn't required.
>
> The argument is that there is no need to allocate a kernel
> object per mutex. That is only one point in the design space,
> and not a very good one.
>
> Do *you* have ADHD is the question.
>

It kind of seems that way, then I sometimes think Bonita is doing it on
purpose. Accusing me of trolling when I suggest using a race detector.
To be quite honest, I don't really trust Bonita's code at all. Then it
wants me to scour through its rather cryptic code and find all of the
bugs, for free. Strange.

On Saturday, September 30, 2023 at 10:07:57 PM UTC+3, Kaz Kylheku wrote:
> On 2023-09-30, Bonita Montero <Bonita....@gmail.com> wrote:
> > Am 30.09.2023 um 05:57 schrieb Pavel:
> >> Bonita Montero wrote:
> >>> Am 29.09.2023 um 03:46 schrieb Pavel:
> >>>
> >>>> see my or Kaz's explanation for how it is done without allocating any
> >>>> kernel resource on either initialization or locking, either fast or
> >>>> slow path.
> >>>
> >>> ... on Linux with signals.
> >>>
> >> With user-space sync primitives on any system.
> >
> > A mutex may lead to a sleeping thread, that's only possible with
> > the help of the kernel.
> You keep returning to this in circles, forgetting that the argument
> isn't that help from the kernel isn't required.
>
> The argument is that there is no need to allocate a kernel
> object per mutex. That is only one point in the design space,
> and not a very good one.
>
> Do *you* have ADHD is the question.
> --
> TXR Programming Language: http://nongnu.org/txr
> Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
> Mastodon: @Kazi...@mstdn.ca
> NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Another point is that "one user-mode lock per one local static object"
is also only one point in the design space. Possibly, not a bad point, if
you have user-mode lock as small as futex on Linux or or even as (slightly
bigger) SRW Lock on Windows's, but it seems that none of major C++ toolsets
had chosen this particular design point. I don't know why.

On 9/30/2023 12:32 PM, Michael S wrote:
> On Saturday, September 30, 2023 at 10:07:57 PM UTC+3, Kaz Kylheku wrote:
>> On 2023-09-30, Bonita Montero <Bonita....@gmail.com> wrote:
>>> Am 30.09.2023 um 05:57 schrieb Pavel:
>>>> Bonita Montero wrote:
>>>>> Am 29.09.2023 um 03:46 schrieb Pavel:
>>>>>
>>>>>> see my or Kaz's explanation for how it is done without allocating any
>>>>>> kernel resource on either initialization or locking, either fast or
>>>>>> slow path.
>>>>>
>>>>> ... on Linux with signals.
>>>>>
>>>> With user-space sync primitives on any system.
>>>
>>> A mutex may lead to a sleeping thread, that's only possible with
>>> the help of the kernel.
>> You keep returning to this in circles, forgetting that the argument
>> isn't that help from the kernel isn't required.
>>
>> The argument is that there is no need to allocate a kernel
>> object per mutex. That is only one point in the design space,
>> and not a very good one.
>>
>> Do *you* have ADHD is the question.
>> --
>> TXR Programming Language: http://nongnu.org/txr
>> Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
>> Mastodon: @Kazi...@mstdn.ca
>> NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
>
> Another point is that "one user-mode lock per one local static object"
> is also only one point in the design space. Possibly, not a bad point, if
> you have user-mode lock as small as futex on Linux or or even as (slightly
> bigger) SRW Lock on Windows's, but it seems that none of major C++ toolsets
> had chosen this particular design point. I don't know why.
>

Probably has something to with with an intra-process mutex failing on
lock even though the user code is 100% perfectly fine is just a really,
really bad idea. Bonita seems to really enjoy projecting its erroneous
ideas on others. Humm...

On 9/30/2023 12:32 PM, Michael S wrote:
> On Saturday, September 30, 2023 at 10:07:57 PM UTC+3, Kaz Kylheku wrote:
>> On 2023-09-30, Bonita Montero <Bonita....@gmail.com> wrote:
>>> Am 30.09.2023 um 05:57 schrieb Pavel:
>>>> Bonita Montero wrote:
>>>>> Am 29.09.2023 um 03:46 schrieb Pavel:
>>>>>
>>>>>> see my or Kaz's explanation for how it is done without allocating any
>>>>>> kernel resource on either initialization or locking, either fast or
>>>>>> slow path.
>>>>>
>>>>> ... on Linux with signals.
>>>>>
>>>> With user-space sync primitives on any system.
>>>
>>> A mutex may lead to a sleeping thread, that's only possible with
>>> the help of the kernel.
>> You keep returning to this in circles, forgetting that the argument
>> isn't that help from the kernel isn't required.
>>
>> The argument is that there is no need to allocate a kernel
>> object per mutex. That is only one point in the design space,
>> and not a very good one.
>>
>> Do *you* have ADHD is the question.
>> --
>> TXR Programming Language: http://nongnu.org/txr
>> Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
>> Mastodon: @Kazi...@mstdn.ca
>> NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
>
> Another point is that "one user-mode lock per one local static object"
> is also only one point in the design space. Possibly, not a bad point, if
> you have user-mode lock as small as futex on Linux or or even as (slightly
> bigger) SRW Lock on Windows's, but it seems that none of major C++ toolsets
> had chosen this particular design point. I don't know why.
>

Actually, one of my rw mutex algorithms allocates all of its kernel
resources up front wrt the object itself. So, the rwmutex can report
this condition wrt failure to create a kernel semaphore, in its
constructor, not on a damn lock() op wrt contention.

Fwiw, a person was kind enough to use my rwmutex work here: Notice it
has no loops? :^)

https://vorbrodt.blog/2019/02/14/read-write-mutex/
(check it out...)

Btw, I have modeled this using several race detectors even though I know
it works. :^)