On 11/8/2023 9:11 PM, Chris M. Thomasson wrote:
> On 11/8/2023 9:08 PM, Bonita Montero wrote:
>> Am 09.11.2023 um 05:42 schrieb Chris M. Thomasson:
>>> On 11/8/2023 8:38 PM, Bonita Montero wrote:
>>>> Am 09.11.2023 um 05:36 schrieb Chris M. Thomasson:
>>>>
>>>>> Humm... Are you okay Bonita? Anything wrong with you?
>>>>
>>>> Hoare monitors relase a waiting thread immediately after a notify()
>>>> and that's less efficient.
>>
>>> Yawn.
>>
>> Re-acquiring the mutex part of a monitor after notify()
>> is an superfluous extra part that takes CPU time.
>
> Look up wait morphing.

Well, I am referring to times of contention.

Am 09.11.2023 um 06:11 schrieb Chris M. Thomasson:
> On 11/8/2023 9:08 PM, Bonita Montero wrote:
>> Am 09.11.2023 um 05:42 schrieb Chris M. Thomasson:
>>> On 11/8/2023 8:38 PM, Bonita Montero wrote:
>>>> Am 09.11.2023 um 05:36 schrieb Chris M. Thomasson:
>>>>
>>>>> Humm... Are you okay Bonita? Anything wrong with you?
>>>>
>>>> Hoare monitors relase a waiting thread immediately after a notify()
>>>> and that's less efficient.
>>
>>> Yawn.
>>
>> Re-acquiring the mutex part of a monitor after notify()
>> is an superfluous extra part that takes CPU time.
>
> Look up wait morphing.

Wait morphing isn't implemented with glibc's condition variables.
My code doen't need that because I'm sleeping on the condvar part
and on the mutex part in *one* step.

On 2023-11-09, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 09.11.2023 um 00:25 schrieb Kaz Kylheku:
>
>> Spurious wakesup are part of the "Mesa semantics" of monitors
>> and condition variables, in contrast to the "Hoare semantics".
>
> Hoare monitors suck since they are less efficient.

Hoare gave us the concept of monitors and condition variables,
which deserves respect.

The original variant is semantically useful; the guarantees that it
provides can make it easier to reason about correctness.

It's something to know about as part of a well-rounded education
in concurrent programming.

--
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 11/8/2023 8:35 PM, Bonita Montero wrote:
> Am 09.11.2023 um 00:32 schrieb Chris M. Thomasson:
>
>> mutex and condition variables happen to be intimately interconnected.
>> Look up wait morphing...
>
> With my implementation registering as a thread wanting to enter the
> mutex and waiting to be notified is one atomic step. That's only
> possible if they're one part.
>

Humm... Sounds good. However, I need to try it out. Also, if you don't
mind I might actually model it in relacy.

On 11/8/2023 9:17 PM, Kaz Kylheku wrote:
> On 2023-11-09, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 09.11.2023 um 00:25 schrieb Kaz Kylheku:
>>
>>> Spurious wakesup are part of the "Mesa semantics" of monitors
>>> and condition variables, in contrast to the "Hoare semantics".
>>
>> Hoare monitors suck since they are less efficient.
>
> Hoare gave us the concept of monitors and condition variables,
> which deserves respect.
>
> The original variant is semantically useful; the guarantees that it
> provides can make it easier to reason about correctness.
>
> It's something to know about as part of a well-rounded education
> in concurrent programming.
>

I concur with that assessment.

Am 09.11.2023 um 06:17 schrieb Kaz Kylheku:

> Hoare gave us the concept of monitors and condition variables,
> which deserves respect.

Hoare monitors are less efficient since they give up ownership
of the mutex part while notifying. That are two kernel calls
which could be prevented.

On 11/8/2023 9:18 PM, Chris M. Thomasson wrote:
> On 11/8/2023 9:17 PM, Kaz Kylheku wrote:
>> On 2023-11-09, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 09.11.2023 um 00:25 schrieb Kaz Kylheku:
>>>
>>>> Spurious wakesup are part of the "Mesa semantics" of monitors
>>>> and condition variables, in contrast to the "Hoare semantics".
>>>
>>> Hoare monitors suck since they are less efficient.
>>
>> Hoare gave us the concept of monitors and condition variables,
>> which deserves respect.
>>
>> The original variant is semantically useful; the guarantees that it
>> provides can make it easier to reason about correctness.
>>
>> It's something to know about as part of a well-rounded education
>> in concurrent programming.
>>
>
> I concur with that assessment.

I wonder if Bontia is pushing things to a borderline. Heck, he/she is
almost making me want to work on it!!!

https://youtu.be/rSaC-YbSDpo

On 11/8/2023 9:19 PM, Bonita Montero wrote:
> Am 09.11.2023 um 06:17 schrieb Kaz Kylheku:
>
>> Hoare gave us the concept of monitors and condition variables,
>> which deserves respect.
>
> Hoare monitors are less efficient since they give up ownership
> of the mutex part while notifying. That are two kernel calls
> which could be prevented.

Avoiding Kernel calls is great.com.

Am 09.11.2023 um 06:17 schrieb Chris M. Thomasson:

> Humm... Sounds good. However, I need to try it out. Also, if you don't
> mind I might actually model it in relacy.

I've witten my own unit test. The Win32 code worked immediately,
but the SysV-code didn't work immediately also because I forgot
to have IPC_NOWAIT while releasing a semaphore. Why is there a
way to wait for the release of a mutex to be accepted by another
thread ? Who comes up with that ?

On 11/8/2023 9:22 PM, Bonita Montero wrote:
> Am 09.11.2023 um 06:17 schrieb Chris M. Thomasson:
>
>> Humm... Sounds good. However, I need to try it out. Also, if you don't
>> mind I might actually model it in relacy.
>
> I've witten my own unit test. The Win32 code worked immediately,
> but the SysV-code didn't work immediately also because I forgot
> to have IPC_NOWAIT while releasing a semaphore. Why is there a
> way to wait for the release of a mutex to be accepted by another
> thread ? Who comes up with that ?

Well, invvvho, it might be prudent of me to model it in Relacy. The act
of me porting your work over into its logic base is going to get me
really intimate with your code.

Am 09.11.2023 um 06:27 schrieb Chris M. Thomasson:

> Well, invvvho, it might be prudent of me to model it in Relacy.
> The act of me porting your work over into its logic base is
> going to get me really intimate with your code.

Just reading the code is easier.

On 11/8/2023 9:27 PM, Chris M. Thomasson wrote:
> On 11/8/2023 9:22 PM, Bonita Montero wrote:
>> Am 09.11.2023 um 06:17 schrieb Chris M. Thomasson:
>>
>>> Humm... Sounds good. However, I need to try it out. Also, if you
>>> don't mind I might actually model it in relacy.
>>
>> I've witten my own unit test. The Win32 code worked immediately,
>> but the SysV-code didn't work immediately also because I forgot
>> to have IPC_NOWAIT while releasing a semaphore. Why is there a
>> way to wait for the release of a mutex to be accepted by another
>> thread ? Who comes up with that ?
>
> Well, invvvho, it might be prudent of me to model it in Relacy. The act
> of me porting your work over into its logic base is going to get me
> really intimate with your code.

Can you feel me? lol. ;^)

I have to work on some of my fractal IFS right now, but, I will try to
port your work over to Relacy. Fwiw, here is a taste of some work I ave
to do right now:

https://paulbourke.net/fractals/multijulia

I am trying to create a nice volumetric form of it.

On 11/8/2023 9:29 PM, Bonita Montero wrote:
> Am 09.11.2023 um 06:27 schrieb Chris M. Thomasson:
>
>> Well, invvvho, it might be prudent of me to model it in Relacy.
>> The act  of me porting your work over into its logic base is
>> going to get me really intimate with your code.
>
> Just reading the code is easier.

Yup. Porting your code to Relacy is going to force me to read every damn
line of your code. So, touche?

On 11/8/2023 9:30 PM, Chris M. Thomasson wrote:
> On 11/8/2023 9:27 PM, Chris M. Thomasson wrote:
>> On 11/8/2023 9:22 PM, Bonita Montero wrote:
>>> Am 09.11.2023 um 06:17 schrieb Chris M. Thomasson:
>>>
>>>> Humm... Sounds good. However, I need to try it out. Also, if you
>>>> don't mind I might actually model it in relacy.
>>>
>>> I've witten my own unit test. The Win32 code worked immediately,
>>> but the SysV-code didn't work immediately also because I forgot
>>> to have IPC_NOWAIT while releasing a semaphore. Why is there a
>>> way to wait for the release of a mutex to be accepted by another
>>> thread ? Who comes up with that ?
>>
>> Well, invvvho, it might be prudent of me to model it in Relacy. The
>> act of me porting your work over into its logic base is going to get
>> me really intimate with your code.
>
> Can you feel me? lol. ;^)
>
> I have to work on some of my fractal IFS right now, but, I will try to
> port your work over to Relacy. Fwiw, here is a taste of some work I ave
> to do right now:
>
> https://paulbourke.net/fractals/multijulia
>
> I am trying to create a nice volumetric form of it.

https://youtu.be/XpbPzrSXOgk

Am 09.11.2023 um 06:31 schrieb Chris M. Thomasson:

> Yup. Porting your code to Relacy is going to force me to read every damn
> line of your code. So, touche?

Reading the code doesn't hurt since the functions are short.

On 11/8/2023 9:17 PM, Bonita Montero wrote:
> Am 09.11.2023 um 06:11 schrieb Chris M. Thomasson:
>> On 11/8/2023 9:08 PM, Bonita Montero wrote:
>>> Am 09.11.2023 um 05:42 schrieb Chris M. Thomasson:
>>>> On 11/8/2023 8:38 PM, Bonita Montero wrote:
>>>>> Am 09.11.2023 um 05:36 schrieb Chris M. Thomasson:
>>>>>
>>>>>> Humm... Are you okay Bonita? Anything wrong with you?
>>>>>
>>>>> Hoare monitors relase a waiting thread immediately after a notify()
>>>>> and that's less efficient.
>>>
>>>> Yawn.
>>>
>>> Re-acquiring the mutex part of a monitor after notify()
>>> is an superfluous extra part that takes CPU time.
>>
>> Look up wait morphing.
>
> Wait morphing isn't implemented with glibc's condition variables.
> My code doen't need that because I'm sleeping on the condvar part
> and on the mutex part in *one* step.
>

Wait morphing is a way that shows how interconnected a mutex actually is
with a condition variable...

On 11/8/2023 9:34 PM, Bonita Montero wrote:
> Am 09.11.2023 um 06:31 schrieb Chris M. Thomasson:
>
>> Yup. Porting your code to Relacy is going to force me to read every
>> damn line of your code. So, touche?
>
> Reading the code doesn't hurt since the functions are short.
>

Porting your code to Relacy makes me read every damn line. You masking
is interesting.

Am 09.11.2023 um 06:35 schrieb Chris M. Thomasson:

> Wait morphing is a way that shows how interconnected a mutex actually is
> with a condition variable...

As you can derive from what I said I know what wait morphing is.
I think wait morphing could be prevented unter systems supporting
SysV seamphores by allocating a semaphore set of two semaphores
for each mutex and leaving the second unused until you have a
condition variable.

Am 09.11.2023 um 06:36 schrieb Chris M. Thomasson:

> Porting your code to Relacy makes me read every damn line.
> You masking is interesting.

My code is understandable if you know MT-primitives
and SysV-IPC. There's nothing "damn" with my code.

On 11/8/2023 9:39 PM, Bonita Montero wrote:
> Am 09.11.2023 um 06:35 schrieb Chris M. Thomasson:
>
>> Wait morphing is a way that shows how interconnected a mutex actually
>> is with a condition variable...
>
> As you can derive from what I said I know what wait morphing is.
> I think wait morphing could be prevented unter systems supporting
> SysV seamphores by allocating a semaphore set of two semaphores
> for each mutex and leaving the second unused until you have a
> condition variable.
>

Can you move waitsets over from mutex to futex and vise versa?

On 11/8/2023 9:40 PM, Chris M. Thomasson wrote:
> On 11/8/2023 9:39 PM, Bonita Montero wrote:
>> Am 09.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>
>>> Wait morphing is a way that shows how interconnected a mutex actually
>>> is with a condition variable...
>>
>> As you can derive from what I said I know what wait morphing is.
>> I think wait morphing could be prevented unter systems supporting
>> SysV seamphores by allocating a semaphore set of two semaphores
>> for each mutex and leaving the second unused until you have a
>> condition variable.
>>
>
> Can you move waitsets over from mutex to futex and vise versa?

This is in the kernel...

On 11/8/2023 9:40 PM, Bonita Montero wrote:
> Am 09.11.2023 um 06:36 schrieb Chris M. Thomasson:
>
>> Porting your code to Relacy makes me read every damn line.
>> You masking is interesting.
>
> My code is understandable if you know MT-primitives
> and SysV-IPC. There's nothing "damn" with my code.

Oh well, like I said, you seem to be a fun person to work with...

Am 09.11.2023 um 06:40 schrieb Chris M. Thomasson:

> Can you move waitsets over from mutex to futex and vise versa?

glibc doesn't do this either.

On 11/8/2023 9:42 PM, Bonita Montero wrote:
> Am 09.11.2023 um 06:40 schrieb Chris M. Thomasson:
>
>> Can you move waitsets over from mutex to futex and vise versa?
>
> glibc doesn't do this either.

Wait morphing is not in the realm of the compiler. It's in the kernel.

On 11/8/2023 9:44 PM, Chris M. Thomasson wrote:
> On 11/8/2023 9:42 PM, Bonita Montero wrote:
>> Am 09.11.2023 um 06:40 schrieb Chris M. Thomasson:
>>
>>> Can you move waitsets over from mutex to futex and vise versa?
>>
>> glibc doesn't do this either.
>
> Wait morphing is not in the realm of the compiler. It's in the kernel.

OOPS! I thought you were talking about gcc. Sorry Bonita!