Am 02.03.2022 um 05:50 schrieb Chris M. Thomasson:
> On 3/1/2022 8:40 PM, Bonita Montero wrote:
>> Am 02.03.2022 um 05:29 schrieb Chris M. Thomasson:
>>> On 3/1/2022 8:12 PM, Bonita Montero wrote:
>>>> Am 02.03.2022 um 04:54 schrieb Chris M. Thomasson:
>>>>> On 3/1/2022 7:45 PM, Bonita Montero wrote:
>>>>>> Am 01.03.2022 um 22:32 schrieb Chris M. Thomasson:
>>>>>>> On 2/28/2022 11:51 PM, Bonita Montero wrote:
>>>>>>>> Am 28.02.2022 um 01:14 schrieb Chris M. Thomasson:
>>>>>>>>> On 2/27/2022 2:35 PM, das...@gmail.com wrote:
>>>>>>>>>> I have 3 variables used as interface variables between 2
>>>>>>>>>> threads. Thread A writes the variables, and Thread B reads
>>>>>>>>>> them.  Let me call them v1, v2, and v3.
>>>>>>>>>>
>>>>>>>>>> I buffer (or snapshot) them into local variables.
>>>>>>>>>>
>>>>>>>>>> Question:  Do the local variables need to be declared volatile
>>>>>>>>>> as well?
>>>>>>>>>
>>>>>>>>> The local variables are fine, and do not need to be
>>>>>>>>> atomic/volatile, ect... Btw, think about using C atomic's
>>>>>>>>> instead of volatile. You might be interested in a seqlock:
>>>>>>>>> https://en.wikipedia.org/wiki/Seqlock
>>>>>>>>> (read all)
>>>>>>>>> They are geared to a read-mostly, write rarely pattern.
>>>>>>>>
>>>>>>>> Seqlocks don't make sense in user-space as they're lock-free and
>>>>>>>> a writer, having made the seq-counter odd, may be easily scheduled
>>>>>>>> away before making the seq-counter even again.
>>>>>>>
>>>>>>> Huh? The writers use a mutex. So, how lock-free is a writer?
>>>>>>> For some reason, I don't think you have ever used one.
>>>>>>
>>>>>> Seqlocks need disabling the scheduler on a core while writing
>>>>>> that a writer can't be scheduled away. That's not possible in
>>>>>> user-mode.
>>>>>
>>>>> Huh? Wow. This basically confirms that you have never used a
>>>>> seqlock in user land. Remember that the writer uses a normal mutex.
>>>>> Now, a friend of mine created a really neat mutation of a seqlock:
>>>>
>>>> No, readers and writers spin.
>>>> Otherwise you don't have a seq-lock but sth. different.
>>>> Look how it is implemented in the Linux kernel.
>>>
>>>
>>> The basic seqlock minus the tricky membars:
>>>
>>> // quick and crude pseudo-code
>>>
>>> struct state { int a = 0; }
>>> mutex g_lock;
>>> atomic_unsigned g_ver = 0;
>>>
>>> state g_state;
>>>
>>> // writers
>>> lock(g_lock);
>>>    ++ver;
>>>
>>>      ++g_state.a;
>>>
>>>    ++ver;
>>> unlock(g_lock);
>>>
>>>
>>> // readers
>>> state lstate;
>>>
>>> for (;;)
>>> {
>>>    unsigned ver0 = g_ver;
>>>
>>>      lstate = g_state;
>>>
>>>    unsigned ver1 = g_ver;
>>>
>>>
>>>    if ((! (ver0 & 1)) && (ver0 == ver1))
>>>    {
>>>       break;
>>>    }
>>>
>>>
>>>    // A reader spun! Humm...
>>>    // yield, backoff, do something else
>>> }
>>>
>>>
>>> The pattern is read-mostly, write-rarely. Fast reads, slow writes. It
>>> works in user-land.
>>
>> Boy, you're so ultimately studpid.
>>
>> Readers could spin for a long time when whe writer is scheduled
>> away. So the approach of 1024 cores is not tolerable in userspace
>> and seqlocks only make sense in kernel space where the writer could
>> disable scheduling while spinning of modifying.
>
> A writer never spins! God damn it. LOL!

With this stupid 1024 cores implementation not.
But the Linux kernel implementation doesn't use mutexes, and the
Linux kernel implementation is the only feasible way to have seqlocks.

> BAM! local_v2 just read v2 outside of the mutex protection. ...

That's not what he actually does.

On 3/1/2022 9:02 PM, Bonita Montero wrote:
> Am 02.03.2022 um 05:50 schrieb Chris M. Thomasson:
>> On 3/1/2022 8:40 PM, Bonita Montero wrote:
>>> Am 02.03.2022 um 05:29 schrieb Chris M. Thomasson:
>>>> On 3/1/2022 8:12 PM, Bonita Montero wrote:
>>>>> Am 02.03.2022 um 04:54 schrieb Chris M. Thomasson:
>>>>>> On 3/1/2022 7:45 PM, Bonita Montero wrote:
>>>>>>> Am 01.03.2022 um 22:32 schrieb Chris M. Thomasson:
>>>>>>>> On 2/28/2022 11:51 PM, Bonita Montero wrote:
>>>>>>>>> Am 28.02.2022 um 01:14 schrieb Chris M. Thomasson:
>>>>>>>>>> On 2/27/2022 2:35 PM, das...@gmail.com wrote:
>>>>>>>>>>> I have 3 variables used as interface variables between 2
>>>>>>>>>>> threads. Thread A writes the variables, and Thread B reads
>>>>>>>>>>> them.  Let me call them v1, v2, and v3.
>>>>>>>>>>>
>>>>>>>>>>> I buffer (or snapshot) them into local variables.
>>>>>>>>>>>
>>>>>>>>>>> Question:  Do the local variables need to be declared
>>>>>>>>>>> volatile as well?
>>>>>>>>>>
>>>>>>>>>> The local variables are fine, and do not need to be
>>>>>>>>>> atomic/volatile, ect... Btw, think about using C atomic's
>>>>>>>>>> instead of volatile. You might be interested in a seqlock:
>>>>>>>>>> https://en.wikipedia.org/wiki/Seqlock
>>>>>>>>>> (read all)
>>>>>>>>>> They are geared to a read-mostly, write rarely pattern.
>>>>>>>>>
>>>>>>>>> Seqlocks don't make sense in user-space as they're lock-free and
>>>>>>>>> a writer, having made the seq-counter odd, may be easily scheduled
>>>>>>>>> away before making the seq-counter even again.
>>>>>>>>
>>>>>>>> Huh? The writers use a mutex. So, how lock-free is a writer?
>>>>>>>> For some reason, I don't think you have ever used one.
>>>>>>>
>>>>>>> Seqlocks need disabling the scheduler on a core while writing
>>>>>>> that a writer can't be scheduled away. That's not possible in
>>>>>>> user-mode.
>>>>>>
>>>>>> Huh? Wow. This basically confirms that you have never used a
>>>>>> seqlock in user land. Remember that the writer uses a normal
>>>>>> mutex. Now, a friend of mine created a really neat mutation of a
>>>>>> seqlock:
>>>>>
>>>>> No, readers and writers spin.
>>>>> Otherwise you don't have a seq-lock but sth. different.
>>>>> Look how it is implemented in the Linux kernel.
>>>>
>>>>
>>>> The basic seqlock minus the tricky membars:
>>>>
>>>> // quick and crude pseudo-code
>>>>
>>>> struct state { int a = 0; }
>>>> mutex g_lock;
>>>> atomic_unsigned g_ver = 0;
>>>>
>>>> state g_state;
>>>>
>>>> // writers
>>>> lock(g_lock);
>>>>    ++ver;
>>>>
>>>>      ++g_state.a;
>>>>
>>>>    ++ver;
>>>> unlock(g_lock);
>>>>
>>>>
>>>> // readers
>>>> state lstate;
>>>>
>>>> for (;;)
>>>> {
>>>>    unsigned ver0 = g_ver;
>>>>
>>>>      lstate = g_state;
>>>>
>>>>    unsigned ver1 = g_ver;
>>>>
>>>>
>>>>    if ((! (ver0 & 1)) && (ver0 == ver1))
>>>>    {
>>>>       break;
>>>>    }
>>>>
>>>>
>>>>    // A reader spun! Humm...
>>>>    // yield, backoff, do something else
>>>> }
>>>>
>>>>
>>>> The pattern is read-mostly, write-rarely. Fast reads, slow writes.
>>>> It works in user-land.
>>>
>>> Boy, you're so ultimately studpid.
>>>
>>> Readers could spin for a long time when whe writer is scheduled
>>> away. So the approach of 1024 cores is not tolerable in userspace
>>> and seqlocks only make sense in kernel space where the writer could
>>> disable scheduling while spinning of modifying.
>>
>> A writer never spins! God damn it. LOL!
>
> With this stupid 1024 cores implementation not.

Huh? A traditional seqlock uses a lock for a writer. You really need to
calm down and read about seqlocks.

> But the Linux kernel implementation doesn't use mutexes, and the
> Linux kernel implementation is the only feasible way to have seqlocks.
>

Sigh.

> Huh? A traditional seqlock uses a lock for a writer. You really need to
> calm down and read about seqlocks.

"Traditional" seqlocks are what the Linux kernel implements.
And this seqlocks don't use mutexes.

Having mutexes is a bad idea because the writer could be scheduled
away and keep the readers spinning for a long time. No one wants
such stupid things in userspace.

Am 02.03.2022 um 06:05 schrieb Chris M. Thomasson:
> On 3/1/2022 9:02 PM, Bonita Montero wrote:
>> Am 02.03.2022 um 05:50 schrieb Chris M. Thomasson:
>>> On 3/1/2022 8:40 PM, Bonita Montero wrote:
>>>> Am 02.03.2022 um 05:29 schrieb Chris M. Thomasson:
>>>>> On 3/1/2022 8:12 PM, Bonita Montero wrote:
>>>>>> Am 02.03.2022 um 04:54 schrieb Chris M. Thomasson:
>>>>>>> On 3/1/2022 7:45 PM, Bonita Montero wrote:
>>>>>>>> Am 01.03.2022 um 22:32 schrieb Chris M. Thomasson:
>>>>>>>>> On 2/28/2022 11:51 PM, Bonita Montero wrote:
>>>>>>>>>> Am 28.02.2022 um 01:14 schrieb Chris M. Thomasson:
>>>>>>>>>>> On 2/27/2022 2:35 PM, das...@gmail.com wrote:
>>>>>>>>>>>> I have 3 variables used as interface variables between 2
>>>>>>>>>>>> threads. Thread A writes the variables, and Thread B reads
>>>>>>>>>>>> them.  Let me call them v1, v2, and v3.
>>>>>>>>>>>>
>>>>>>>>>>>> I buffer (or snapshot) them into local variables.
>>>>>>>>>>>>
>>>>>>>>>>>> Question:  Do the local variables need to be declared
>>>>>>>>>>>> volatile as well?
>>>>>>>>>>>
>>>>>>>>>>> The local variables are fine, and do not need to be
>>>>>>>>>>> atomic/volatile, ect... Btw, think about using C atomic's
>>>>>>>>>>> instead of volatile. You might be interested in a seqlock:
>>>>>>>>>>> https://en.wikipedia.org/wiki/Seqlock
>>>>>>>>>>> (read all)
>>>>>>>>>>> They are geared to a read-mostly, write rarely pattern.
>>>>>>>>>>
>>>>>>>>>> Seqlocks don't make sense in user-space as they're lock-free and
>>>>>>>>>> a writer, having made the seq-counter odd, may be easily
>>>>>>>>>> scheduled
>>>>>>>>>> away before making the seq-counter even again.
>>>>>>>>>
>>>>>>>>> Huh? The writers use a mutex. So, how lock-free is a writer?
>>>>>>>>> For some reason, I don't think you have ever used one.
>>>>>>>>
>>>>>>>> Seqlocks need disabling the scheduler on a core while writing
>>>>>>>> that a writer can't be scheduled away. That's not possible in
>>>>>>>> user-mode.
>>>>>>>
>>>>>>> Huh? Wow. This basically confirms that you have never used a
>>>>>>> seqlock in user land. Remember that the writer uses a normal
>>>>>>> mutex. Now, a friend of mine created a really neat mutation of a
>>>>>>> seqlock:
>>>>>>
>>>>>> No, readers and writers spin.
>>>>>> Otherwise you don't have a seq-lock but sth. different.
>>>>>> Look how it is implemented in the Linux kernel.
>>>>>
>>>>>
>>>>> The basic seqlock minus the tricky membars:
>>>>>
>>>>> // quick and crude pseudo-code
>>>>>
>>>>> struct state { int a = 0; }
>>>>> mutex g_lock;
>>>>> atomic_unsigned g_ver = 0;
>>>>>
>>>>> state g_state;
>>>>>
>>>>> // writers
>>>>> lock(g_lock);
>>>>>    ++ver;
>>>>>
>>>>>      ++g_state.a;
>>>>>
>>>>>    ++ver;
>>>>> unlock(g_lock);
>>>>>
>>>>>
>>>>> // readers
>>>>> state lstate;
>>>>>
>>>>> for (;;)
>>>>> {
>>>>>    unsigned ver0 = g_ver;
>>>>>
>>>>>      lstate = g_state;
>>>>>
>>>>>    unsigned ver1 = g_ver;
>>>>>
>>>>>
>>>>>    if ((! (ver0 & 1)) && (ver0 == ver1))
>>>>>    {
>>>>>       break;
>>>>>    }
>>>>>
>>>>>
>>>>>    // A reader spun! Humm...
>>>>>    // yield, backoff, do something else
>>>>> }
>>>>>
>>>>>
>>>>> The pattern is read-mostly, write-rarely. Fast reads, slow writes.
>>>>> It works in user-land.
>>>>
>>>> Boy, you're so ultimately studpid.
>>>>
>>>> Readers could spin for a long time when whe writer is scheduled
>>>> away. So the approach of 1024 cores is not tolerable in userspace
>>>> and seqlocks only make sense in kernel space where the writer could
>>>> disable scheduling while spinning of modifying.
>>>
>>> A writer never spins! God damn it. LOL!
>>
>> With this stupid 1024 cores implementation not.
>
> Huh? A traditional seqlock uses a lock for a writer. You really need to
> calm down and read about seqlocks.

That's linux seqlock-structure:

typedef struct {
struct seqcount seqcount;
spinlock_t lock;
} seqlock_t;

Where's the mutex ?

On 3/1/2022 9:05 PM, Bonita Montero wrote:
>> BAM! local_v2 just read v2 outside of the mutex protection. ...
>
> That's not what he actually does.
>

Oh yes he does! Calm down and read it again.

ThreadA:

A[0] MUTEX_BEGIN();
A[1] v1 = expression1;
A[2] MUTEX_END();
...
A[3] MUTEX_BEGIN();
A[4] v2 = expression2;
A[5] MUTEX_END();
...
A[6] MUTEX_BEGIN();
A[7] v3 = expression3;
A[8] MUTEX_END();

ThreadB:

B[0] MUTEX_BEGIN();
B[1] buf_v1 = v1;
B[2] buf_v2 = v2;
B[3] buf_v3 = v3;
B[4] MUTEX_END();

The following sequence requires atomics:

A[0]
A[1]
A[2]
B[0]
B[1]
B[2] BAM! we just read v2 outside of mutex protection!

End of game. Needs atomics to comply with the standard.

On 3/1/2022 9:09 PM, Bonita Montero wrote:
> Am 02.03.2022 um 06:05 schrieb Chris M. Thomasson:
>> On 3/1/2022 9:02 PM, Bonita Montero wrote:
>>> Am 02.03.2022 um 05:50 schrieb Chris M. Thomasson:
>>>> On 3/1/2022 8:40 PM, Bonita Montero wrote:
>>>>> Am 02.03.2022 um 05:29 schrieb Chris M. Thomasson:
>>>>>> On 3/1/2022 8:12 PM, Bonita Montero wrote:
>>>>>>> Am 02.03.2022 um 04:54 schrieb Chris M. Thomasson:
>>>>>>>> On 3/1/2022 7:45 PM, Bonita Montero wrote:
>>>>>>>>> Am 01.03.2022 um 22:32 schrieb Chris M. Thomasson:
>>>>>>>>>> On 2/28/2022 11:51 PM, Bonita Montero wrote:
>>>>>>>>>>> Am 28.02.2022 um 01:14 schrieb Chris M. Thomasson:
>>>>>>>>>>>> On 2/27/2022 2:35 PM, das...@gmail.com wrote:
>>>>>>>>>>>>> I have 3 variables used as interface variables between 2
>>>>>>>>>>>>> threads. Thread A writes the variables, and Thread B reads
>>>>>>>>>>>>> them.  Let me call them v1, v2, and v3.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I buffer (or snapshot) them into local variables.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Question:  Do the local variables need to be declared
>>>>>>>>>>>>> volatile as well?
>>>>>>>>>>>>
>>>>>>>>>>>> The local variables are fine, and do not need to be
>>>>>>>>>>>> atomic/volatile, ect... Btw, think about using C atomic's
>>>>>>>>>>>> instead of volatile. You might be interested in a seqlock:
>>>>>>>>>>>> https://en.wikipedia.org/wiki/Seqlock
>>>>>>>>>>>> (read all)
>>>>>>>>>>>> They are geared to a read-mostly, write rarely pattern.
>>>>>>>>>>>
>>>>>>>>>>> Seqlocks don't make sense in user-space as they're lock-free and
>>>>>>>>>>> a writer, having made the seq-counter odd, may be easily
>>>>>>>>>>> scheduled
>>>>>>>>>>> away before making the seq-counter even again.
>>>>>>>>>>
>>>>>>>>>> Huh? The writers use a mutex. So, how lock-free is a writer?
>>>>>>>>>> For some reason, I don't think you have ever used one.
>>>>>>>>>
>>>>>>>>> Seqlocks need disabling the scheduler on a core while writing
>>>>>>>>> that a writer can't be scheduled away. That's not possible in
>>>>>>>>> user-mode.
>>>>>>>>
>>>>>>>> Huh? Wow. This basically confirms that you have never used a
>>>>>>>> seqlock in user land. Remember that the writer uses a normal
>>>>>>>> mutex. Now, a friend of mine created a really neat mutation of a
>>>>>>>> seqlock:
>>>>>>>
>>>>>>> No, readers and writers spin.
>>>>>>> Otherwise you don't have a seq-lock but sth. different.
>>>>>>> Look how it is implemented in the Linux kernel.
>>>>>>
>>>>>>
>>>>>> The basic seqlock minus the tricky membars:
>>>>>>
>>>>>> // quick and crude pseudo-code
>>>>>>
>>>>>> struct state { int a = 0; }
>>>>>> mutex g_lock;
>>>>>> atomic_unsigned g_ver = 0;
>>>>>>
>>>>>> state g_state;
>>>>>>
>>>>>> // writers
>>>>>> lock(g_lock);
>>>>>>    ++ver;
>>>>>>
>>>>>>      ++g_state.a;
>>>>>>
>>>>>>    ++ver;
>>>>>> unlock(g_lock);
>>>>>>
>>>>>>
>>>>>> // readers
>>>>>> state lstate;
>>>>>>
>>>>>> for (;;)
>>>>>> {
>>>>>>    unsigned ver0 = g_ver;
>>>>>>
>>>>>>      lstate = g_state;
>>>>>>
>>>>>>    unsigned ver1 = g_ver;
>>>>>>
>>>>>>
>>>>>>    if ((! (ver0 & 1)) && (ver0 == ver1))
>>>>>>    {
>>>>>>       break;
>>>>>>    }
>>>>>>
>>>>>>
>>>>>>    // A reader spun! Humm...
>>>>>>    // yield, backoff, do something else
>>>>>> }
>>>>>>
>>>>>>
>>>>>> The pattern is read-mostly, write-rarely. Fast reads, slow writes.
>>>>>> It works in user-land.
>>>>>
>>>>> Boy, you're so ultimately studpid.
>>>>>
>>>>> Readers could spin for a long time when whe writer is scheduled
>>>>> away. So the approach of 1024 cores is not tolerable in userspace
>>>>> and seqlocks only make sense in kernel space where the writer could
>>>>> disable scheduling while spinning of modifying.
>>>>
>>>> A writer never spins! God damn it. LOL!
>>>
>>> With this stupid 1024 cores implementation not.
>>
>> Huh? A traditional seqlock uses a lock for a writer. You really need
>> to calm down and read about seqlocks.
>
> That's linux seqlock-structure:
>
> typedef struct {
>     struct seqcount seqcount;
>     spinlock_t lock;
> } seqlock_t;
>
> Where's the mutex ?

Humm... I am going to guess that the spinlock_t is the mutual exclusion
lock here. LOL! Are you kidding me?

Am 02.03.2022 um 06:09 schrieb Chris M. Thomasson:
> On 3/1/2022 9:05 PM, Bonita Montero wrote:
>>> BAM! local_v2 just read v2 outside of the mutex protection. ...
>>
>> That's not what he actually does.
>>
>
> Oh yes he does! Calm down and read it again.

No, his volatile-accesses are _all_ guarded my mutexes and I said
that when the mutexes include proper barriers volatile isn't needed.

Am 02.03.2022 um 06:10 schrieb Chris M. Thomasson:
> On 3/1/2022 9:09 PM, Bonita Montero wrote:
>> Am 02.03.2022 um 06:05 schrieb Chris M. Thomasson:
>>> On 3/1/2022 9:02 PM, Bonita Montero wrote:
>>>> Am 02.03.2022 um 05:50 schrieb Chris M. Thomasson:
>>>>> On 3/1/2022 8:40 PM, Bonita Montero wrote:
>>>>>> Am 02.03.2022 um 05:29 schrieb Chris M. Thomasson:
>>>>>>> On 3/1/2022 8:12 PM, Bonita Montero wrote:
>>>>>>>> Am 02.03.2022 um 04:54 schrieb Chris M. Thomasson:
>>>>>>>>> On 3/1/2022 7:45 PM, Bonita Montero wrote:
>>>>>>>>>> Am 01.03.2022 um 22:32 schrieb Chris M. Thomasson:
>>>>>>>>>>> On 2/28/2022 11:51 PM, Bonita Montero wrote:
>>>>>>>>>>>> Am 28.02.2022 um 01:14 schrieb Chris M. Thomasson:
>>>>>>>>>>>>> On 2/27/2022 2:35 PM, das...@gmail.com wrote:
>>>>>>>>>>>>>> I have 3 variables used as interface variables between 2
>>>>>>>>>>>>>> threads. Thread A writes the variables, and Thread B reads
>>>>>>>>>>>>>> them.  Let me call them v1, v2, and v3.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I buffer (or snapshot) them into local variables.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Question:  Do the local variables need to be declared
>>>>>>>>>>>>>> volatile as well?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The local variables are fine, and do not need to be
>>>>>>>>>>>>> atomic/volatile, ect... Btw, think about using C atomic's
>>>>>>>>>>>>> instead of volatile. You might be interested in a seqlock:
>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Seqlock
>>>>>>>>>>>>> (read all)
>>>>>>>>>>>>> They are geared to a read-mostly, write rarely pattern.
>>>>>>>>>>>>
>>>>>>>>>>>> Seqlocks don't make sense in user-space as they're lock-free
>>>>>>>>>>>> and
>>>>>>>>>>>> a writer, having made the seq-counter odd, may be easily
>>>>>>>>>>>> scheduled
>>>>>>>>>>>> away before making the seq-counter even again.
>>>>>>>>>>>
>>>>>>>>>>> Huh? The writers use a mutex. So, how lock-free is a writer?
>>>>>>>>>>> For some reason, I don't think you have ever used one.
>>>>>>>>>>
>>>>>>>>>> Seqlocks need disabling the scheduler on a core while writing
>>>>>>>>>> that a writer can't be scheduled away. That's not possible in
>>>>>>>>>> user-mode.
>>>>>>>>>
>>>>>>>>> Huh? Wow. This basically confirms that you have never used a
>>>>>>>>> seqlock in user land. Remember that the writer uses a normal
>>>>>>>>> mutex. Now, a friend of mine created a really neat mutation of
>>>>>>>>> a seqlock:
>>>>>>>>
>>>>>>>> No, readers and writers spin.
>>>>>>>> Otherwise you don't have a seq-lock but sth. different.
>>>>>>>> Look how it is implemented in the Linux kernel.
>>>>>>>
>>>>>>>
>>>>>>> The basic seqlock minus the tricky membars:
>>>>>>>
>>>>>>> // quick and crude pseudo-code
>>>>>>>
>>>>>>> struct state { int a = 0; }
>>>>>>> mutex g_lock;
>>>>>>> atomic_unsigned g_ver = 0;
>>>>>>>
>>>>>>> state g_state;
>>>>>>>
>>>>>>> // writers
>>>>>>> lock(g_lock);
>>>>>>>    ++ver;
>>>>>>>
>>>>>>>      ++g_state.a;
>>>>>>>
>>>>>>>    ++ver;
>>>>>>> unlock(g_lock);
>>>>>>>
>>>>>>>
>>>>>>> // readers
>>>>>>> state lstate;
>>>>>>>
>>>>>>> for (;;)
>>>>>>> {
>>>>>>>    unsigned ver0 = g_ver;
>>>>>>>
>>>>>>>      lstate = g_state;
>>>>>>>
>>>>>>>    unsigned ver1 = g_ver;
>>>>>>>
>>>>>>>
>>>>>>>    if ((! (ver0 & 1)) && (ver0 == ver1))
>>>>>>>    {
>>>>>>>       break;
>>>>>>>    }
>>>>>>>
>>>>>>>
>>>>>>>    // A reader spun! Humm...
>>>>>>>    // yield, backoff, do something else
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> The pattern is read-mostly, write-rarely. Fast reads, slow
>>>>>>> writes. It works in user-land.
>>>>>>
>>>>>> Boy, you're so ultimately studpid.
>>>>>>
>>>>>> Readers could spin for a long time when whe writer is scheduled
>>>>>> away. So the approach of 1024 cores is not tolerable in userspace
>>>>>> and seqlocks only make sense in kernel space where the writer could
>>>>>> disable scheduling while spinning of modifying.
>>>>>
>>>>> A writer never spins! God damn it. LOL!
>>>>
>>>> With this stupid 1024 cores implementation not.
>>>
>>> Huh? A traditional seqlock uses a lock for a writer. You really need
>>> to calm down and read about seqlocks.
>>
>> That's linux seqlock-structure:
>>
>> typedef struct {
>>      struct seqcount seqcount;
>>      spinlock_t lock;
>> } seqlock_t;
>>
>> Where's the mutex ?
>
> Humm... I am going to guess that the spinlock_t is the mutual exclusion
> lock here. LOL! Are you kidding me?

spinlock_t is a spinlock, and not a mutex.
Linux kernel seqlocks don't include a mutex.

On 3/1/2022 9:11 PM, Bonita Montero wrote:
> Am 02.03.2022 um 06:09 schrieb Chris M. Thomasson:
>> On 3/1/2022 9:05 PM, Bonita Montero wrote:
>>>> BAM! local_v2 just read v2 outside of the mutex protection. ...
>>>
>>> That's not what he actually does.
>>>
>>
>> Oh yes he does! Calm down and read it again.
>
> No, his volatile-accesses are _all_ guarded my mutexes and I said
> that when the mutexes include proper barriers volatile isn't needed.

I know it works because of that for sure, however, for some damn reason
I still think this needs atomics with relaxed membars to be 100%
standard compliant wrt C.

On 3/1/2022 9:12 PM, Bonita Montero wrote:
> Am 02.03.2022 um 06:10 schrieb Chris M. Thomasson:
>> On 3/1/2022 9:09 PM, Bonita Montero wrote:
>>> Am 02.03.2022 um 06:05 schrieb Chris M. Thomasson:
>>>> On 3/1/2022 9:02 PM, Bonita Montero wrote:
>>>>> Am 02.03.2022 um 05:50 schrieb Chris M. Thomasson:
>>>>>> On 3/1/2022 8:40 PM, Bonita Montero wrote:
>>>>>>> Am 02.03.2022 um 05:29 schrieb Chris M. Thomasson:
>>>>>>>> On 3/1/2022 8:12 PM, Bonita Montero wrote:
>>>>>>>>> Am 02.03.2022 um 04:54 schrieb Chris M. Thomasson:
>>>>>>>>>> On 3/1/2022 7:45 PM, Bonita Montero wrote:
>>>>>>>>>>> Am 01.03.2022 um 22:32 schrieb Chris M. Thomasson:
>>>>>>>>>>>> On 2/28/2022 11:51 PM, Bonita Montero wrote:
>>>>>>>>>>>>> Am 28.02.2022 um 01:14 schrieb Chris M. Thomasson:
>>>>>>>>>>>>>> On 2/27/2022 2:35 PM, das...@gmail.com wrote:
>>>>>>>>>>>>>>> I have 3 variables used as interface variables between 2
>>>>>>>>>>>>>>> threads. Thread A writes the variables, and Thread B
>>>>>>>>>>>>>>> reads them.  Let me call them v1, v2, and v3.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I buffer (or snapshot) them into local variables.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Question:  Do the local variables need to be declared
>>>>>>>>>>>>>>> volatile as well?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The local variables are fine, and do not need to be
>>>>>>>>>>>>>> atomic/volatile, ect... Btw, think about using C atomic's
>>>>>>>>>>>>>> instead of volatile. You might be interested in a seqlock:
>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Seqlock
>>>>>>>>>>>>>> (read all)
>>>>>>>>>>>>>> They are geared to a read-mostly, write rarely pattern.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Seqlocks don't make sense in user-space as they're
>>>>>>>>>>>>> lock-free and
>>>>>>>>>>>>> a writer, having made the seq-counter odd, may be easily
>>>>>>>>>>>>> scheduled
>>>>>>>>>>>>> away before making the seq-counter even again.
>>>>>>>>>>>>
>>>>>>>>>>>> Huh? The writers use a mutex. So, how lock-free is a writer?
>>>>>>>>>>>> For some reason, I don't think you have ever used one.
>>>>>>>>>>>
>>>>>>>>>>> Seqlocks need disabling the scheduler on a core while writing
>>>>>>>>>>> that a writer can't be scheduled away. That's not possible in
>>>>>>>>>>> user-mode.
>>>>>>>>>>
>>>>>>>>>> Huh? Wow. This basically confirms that you have never used a
>>>>>>>>>> seqlock in user land. Remember that the writer uses a normal
>>>>>>>>>> mutex. Now, a friend of mine created a really neat mutation of
>>>>>>>>>> a seqlock:
>>>>>>>>>
>>>>>>>>> No, readers and writers spin.
>>>>>>>>> Otherwise you don't have a seq-lock but sth. different.
>>>>>>>>> Look how it is implemented in the Linux kernel.
>>>>>>>>
>>>>>>>>
>>>>>>>> The basic seqlock minus the tricky membars:
>>>>>>>>
>>>>>>>> // quick and crude pseudo-code
>>>>>>>>
>>>>>>>> struct state { int a = 0; }
>>>>>>>> mutex g_lock;
>>>>>>>> atomic_unsigned g_ver = 0;
>>>>>>>>
>>>>>>>> state g_state;
>>>>>>>>
>>>>>>>> // writers
>>>>>>>> lock(g_lock);
>>>>>>>>    ++ver;
>>>>>>>>
>>>>>>>>      ++g_state.a;
>>>>>>>>
>>>>>>>>    ++ver;
>>>>>>>> unlock(g_lock);
>>>>>>>>
>>>>>>>>
>>>>>>>> // readers
>>>>>>>> state lstate;
>>>>>>>>
>>>>>>>> for (;;)
>>>>>>>> {
>>>>>>>>    unsigned ver0 = g_ver;
>>>>>>>>
>>>>>>>>      lstate = g_state;
>>>>>>>>
>>>>>>>>    unsigned ver1 = g_ver;
>>>>>>>>
>>>>>>>>
>>>>>>>>    if ((! (ver0 & 1)) && (ver0 == ver1))
>>>>>>>>    {
>>>>>>>>       break;
>>>>>>>>    }
>>>>>>>>
>>>>>>>>
>>>>>>>>    // A reader spun! Humm...
>>>>>>>>    // yield, backoff, do something else
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> The pattern is read-mostly, write-rarely. Fast reads, slow
>>>>>>>> writes. It works in user-land.
>>>>>>>
>>>>>>> Boy, you're so ultimately studpid.
>>>>>>>
>>>>>>> Readers could spin for a long time when whe writer is scheduled
>>>>>>> away. So the approach of 1024 cores is not tolerable in userspace
>>>>>>> and seqlocks only make sense in kernel space where the writer could
>>>>>>> disable scheduling while spinning of modifying.
>>>>>>
>>>>>> A writer never spins! God damn it. LOL!
>>>>>
>>>>> With this stupid 1024 cores implementation not.
>>>>
>>>> Huh? A traditional seqlock uses a lock for a writer. You really need
>>>> to calm down and read about seqlocks.
>>>
>>> That's linux seqlock-structure:
>>>
>>> typedef struct {
>>>      struct seqcount seqcount;
>>>      spinlock_t lock;
>>> } seqlock_t;
>>>
>>> Where's the mutex ?
>>
>> Humm... I am going to guess that the spinlock_t is the mutual
>> exclusion lock here. LOL! Are you kidding me?
>
> spinlock_t is a spinlock, and not a mutex.
> Linux kernel seqlocks don't include a mutex.

Using a mutex in user land is fine! Using a seqlock with a mutex in
userland is fine as long as your usage pattern fits in with read-mostly,
write rarely.

Am 02.03.2022 um 06:19 schrieb Chris M. Thomasson:
> On 3/1/2022 9:11 PM, Bonita Montero wrote:
>> Am 02.03.2022 um 06:09 schrieb Chris M. Thomasson:
>>> On 3/1/2022 9:05 PM, Bonita Montero wrote:
>>>>> BAM! local_v2 just read v2 outside of the mutex protection. ...
>>>>
>>>> That's not what he actually does.
>>>>
>>>
>>> Oh yes he does! Calm down and read it again.
>>
>> No, his volatile-accesses are _all_ guarded my mutexes and I said
>> that when the mutexes include proper barriers volatile isn't needed.
>
> I know it works because of that for sure, ...

We're talking about his code and that volatiles aren't necessary
and not what you're dreaming about.

Am 02.03.2022 um 06:21 schrieb Chris M. Thomasson:
> On 3/1/2022 9:12 PM, Bonita Montero wrote:
>> Am 02.03.2022 um 06:10 schrieb Chris M. Thomasson:
>>> On 3/1/2022 9:09 PM, Bonita Montero wrote:
>>>> Am 02.03.2022 um 06:05 schrieb Chris M. Thomasson:
>>>>> On 3/1/2022 9:02 PM, Bonita Montero wrote:
>>>>>> Am 02.03.2022 um 05:50 schrieb Chris M. Thomasson:
>>>>>>> On 3/1/2022 8:40 PM, Bonita Montero wrote:
>>>>>>>> Am 02.03.2022 um 05:29 schrieb Chris M. Thomasson:
>>>>>>>>> On 3/1/2022 8:12 PM, Bonita Montero wrote:
>>>>>>>>>> Am 02.03.2022 um 04:54 schrieb Chris M. Thomasson:
>>>>>>>>>>> On 3/1/2022 7:45 PM, Bonita Montero wrote:
>>>>>>>>>>>> Am 01.03.2022 um 22:32 schrieb Chris M. Thomasson:
>>>>>>>>>>>>> On 2/28/2022 11:51 PM, Bonita Montero wrote:
>>>>>>>>>>>>>> Am 28.02.2022 um 01:14 schrieb Chris M. Thomasson:
>>>>>>>>>>>>>>> On 2/27/2022 2:35 PM, das...@gmail.com wrote:
>>>>>>>>>>>>>>>> I have 3 variables used as interface variables between 2
>>>>>>>>>>>>>>>> threads. Thread A writes the variables, and Thread B
>>>>>>>>>>>>>>>> reads them.  Let me call them v1, v2, and v3.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I buffer (or snapshot) them into local variables.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Question:  Do the local variables need to be declared
>>>>>>>>>>>>>>>> volatile as well?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The local variables are fine, and do not need to be
>>>>>>>>>>>>>>> atomic/volatile, ect... Btw, think about using C atomic's
>>>>>>>>>>>>>>> instead of volatile. You might be interested in a seqlock:
>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Seqlock
>>>>>>>>>>>>>>> (read all)
>>>>>>>>>>>>>>> They are geared to a read-mostly, write rarely pattern.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Seqlocks don't make sense in user-space as they're
>>>>>>>>>>>>>> lock-free and
>>>>>>>>>>>>>> a writer, having made the seq-counter odd, may be easily
>>>>>>>>>>>>>> scheduled
>>>>>>>>>>>>>> away before making the seq-counter even again.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Huh? The writers use a mutex. So, how lock-free is a writer?
>>>>>>>>>>>>> For some reason, I don't think you have ever used one.
>>>>>>>>>>>>
>>>>>>>>>>>> Seqlocks need disabling the scheduler on a core while writing
>>>>>>>>>>>> that a writer can't be scheduled away. That's not possible in
>>>>>>>>>>>> user-mode.
>>>>>>>>>>>
>>>>>>>>>>> Huh? Wow. This basically confirms that you have never used a
>>>>>>>>>>> seqlock in user land. Remember that the writer uses a normal
>>>>>>>>>>> mutex. Now, a friend of mine created a really neat mutation
>>>>>>>>>>> of a seqlock:
>>>>>>>>>>
>>>>>>>>>> No, readers and writers spin.
>>>>>>>>>> Otherwise you don't have a seq-lock but sth. different.
>>>>>>>>>> Look how it is implemented in the Linux kernel.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The basic seqlock minus the tricky membars:
>>>>>>>>>
>>>>>>>>> // quick and crude pseudo-code
>>>>>>>>>
>>>>>>>>> struct state { int a = 0; }
>>>>>>>>> mutex g_lock;
>>>>>>>>> atomic_unsigned g_ver = 0;
>>>>>>>>>
>>>>>>>>> state g_state;
>>>>>>>>>
>>>>>>>>> // writers
>>>>>>>>> lock(g_lock);
>>>>>>>>>    ++ver;
>>>>>>>>>
>>>>>>>>>      ++g_state.a;
>>>>>>>>>
>>>>>>>>>    ++ver;
>>>>>>>>> unlock(g_lock);
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> // readers
>>>>>>>>> state lstate;
>>>>>>>>>
>>>>>>>>> for (;;)
>>>>>>>>> {
>>>>>>>>>    unsigned ver0 = g_ver;
>>>>>>>>>
>>>>>>>>>      lstate = g_state;
>>>>>>>>>
>>>>>>>>>    unsigned ver1 = g_ver;
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    if ((! (ver0 & 1)) && (ver0 == ver1))
>>>>>>>>>    {
>>>>>>>>>       break;
>>>>>>>>>    }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    // A reader spun! Humm...
>>>>>>>>>    // yield, backoff, do something else
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The pattern is read-mostly, write-rarely. Fast reads, slow
>>>>>>>>> writes. It works in user-land.
>>>>>>>>
>>>>>>>> Boy, you're so ultimately studpid.
>>>>>>>>
>>>>>>>> Readers could spin for a long time when whe writer is scheduled
>>>>>>>> away. So the approach of 1024 cores is not tolerable in userspace
>>>>>>>> and seqlocks only make sense in kernel space where the writer could
>>>>>>>> disable scheduling while spinning of modifying.
>>>>>>>
>>>>>>> A writer never spins! God damn it. LOL!
>>>>>>
>>>>>> With this stupid 1024 cores implementation not.
>>>>>
>>>>> Huh? A traditional seqlock uses a lock for a writer. You really
>>>>> need to calm down and read about seqlocks.
>>>>
>>>> That's linux seqlock-structure:
>>>>
>>>> typedef struct {
>>>>      struct seqcount seqcount;
>>>>      spinlock_t lock;
>>>> } seqlock_t;
>>>>
>>>> Where's the mutex ?
>>>
>>> Humm... I am going to guess that the spinlock_t is the mutual
>>> exclusion lock here. LOL! Are you kidding me?
>>
>> spinlock_t is a spinlock, and not a mutex.
>> Linux kernel seqlocks don't include a mutex.
>
> Using a mutex in user land is fine! Using a seqlock with a mutex in
> userland is fine as long as your usage pattern fits in with read-mostly,
> write rarely.

Using mutexes for "seqlocks" on the writer-side doesn't preserve the
readers from spinning. So seqlocks in user-space implmented in that
way are a strupid idea.

On 3/1/2022 9:24 PM, Bonita Montero wrote:
> Am 02.03.2022 um 06:19 schrieb Chris M. Thomasson:
>> On 3/1/2022 9:11 PM, Bonita Montero wrote:
>>> Am 02.03.2022 um 06:09 schrieb Chris M. Thomasson:
>>>> On 3/1/2022 9:05 PM, Bonita Montero wrote:
>>>>>> BAM! local_v2 just read v2 outside of the mutex protection. ...
>>>>>
>>>>> That's not what he actually does.
>>>>>
>>>>
>>>> Oh yes he does! Calm down and read it again.
>>>
>>> No, his volatile-accesses are _all_ guarded my mutexes and I said
>>> that when the mutexes include proper barriers volatile isn't needed.
>>
>> I know it works because of that for sure, ...
>
> We're talking about his code and that volatiles aren't necessary
> and not what you're dreaming about.
>

Yeah. You are right, but iirc there was some odd wording in the C11
standard that it might violate. I need to refresh myself.

On 3/1/2022 9:25 PM, Bonita Montero wrote:
> Am 02.03.2022 um 06:21 schrieb Chris M. Thomasson:
>> On 3/1/2022 9:12 PM, Bonita Montero wrote:
>>> Am 02.03.2022 um 06:10 schrieb Chris M. Thomasson:
>>>> On 3/1/2022 9:09 PM, Bonita Montero wrote:
>>>>> Am 02.03.2022 um 06:05 schrieb Chris M. Thomasson:
>>>>>> On 3/1/2022 9:02 PM, Bonita Montero wrote:
>>>>>>> Am 02.03.2022 um 05:50 schrieb Chris M. Thomasson:
>>>>>>>> On 3/1/2022 8:40 PM, Bonita Montero wrote:
>>>>>>>>> Am 02.03.2022 um 05:29 schrieb Chris M. Thomasson:
>>>>>>>>>> On 3/1/2022 8:12 PM, Bonita Montero wrote:
>>>>>>>>>>> Am 02.03.2022 um 04:54 schrieb Chris M. Thomasson:
>>>>>>>>>>>> On 3/1/2022 7:45 PM, Bonita Montero wrote:
>>>>>>>>>>>>> Am 01.03.2022 um 22:32 schrieb Chris M. Thomasson:
>>>>>>>>>>>>>> On 2/28/2022 11:51 PM, Bonita Montero wrote:
>>>>>>>>>>>>>>> Am 28.02.2022 um 01:14 schrieb Chris M. Thomasson:
>>>>>>>>>>>>>>>> On 2/27/2022 2:35 PM, das...@gmail.com wrote:
>>>>>>>>>>>>>>>>> I have 3 variables used as interface variables between
>>>>>>>>>>>>>>>>> 2 threads. Thread A writes the variables, and Thread B
>>>>>>>>>>>>>>>>> reads them.  Let me call them v1, v2, and v3.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I buffer (or snapshot) them into local variables.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Question:  Do the local variables need to be declared
>>>>>>>>>>>>>>>>> volatile as well?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The local variables are fine, and do not need to be
>>>>>>>>>>>>>>>> atomic/volatile, ect... Btw, think about using C
>>>>>>>>>>>>>>>> atomic's instead of volatile. You might be interested in
>>>>>>>>>>>>>>>> a seqlock:
>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Seqlock
>>>>>>>>>>>>>>>> (read all)
>>>>>>>>>>>>>>>> They are geared to a read-mostly, write rarely pattern.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Seqlocks don't make sense in user-space as they're
>>>>>>>>>>>>>>> lock-free and
>>>>>>>>>>>>>>> a writer, having made the seq-counter odd, may be easily
>>>>>>>>>>>>>>> scheduled
>>>>>>>>>>>>>>> away before making the seq-counter even again.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Huh? The writers use a mutex. So, how lock-free is a writer?
>>>>>>>>>>>>>> For some reason, I don't think you have ever used one.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Seqlocks need disabling the scheduler on a core while writing
>>>>>>>>>>>>> that a writer can't be scheduled away. That's not possible in
>>>>>>>>>>>>> user-mode.
>>>>>>>>>>>>
>>>>>>>>>>>> Huh? Wow. This basically confirms that you have never used a
>>>>>>>>>>>> seqlock in user land. Remember that the writer uses a normal
>>>>>>>>>>>> mutex. Now, a friend of mine created a really neat mutation
>>>>>>>>>>>> of a seqlock:
>>>>>>>>>>>
>>>>>>>>>>> No, readers and writers spin.
>>>>>>>>>>> Otherwise you don't have a seq-lock but sth. different.
>>>>>>>>>>> Look how it is implemented in the Linux kernel.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The basic seqlock minus the tricky membars:
>>>>>>>>>>
>>>>>>>>>> // quick and crude pseudo-code
>>>>>>>>>>
>>>>>>>>>> struct state { int a = 0; }
>>>>>>>>>> mutex g_lock;
>>>>>>>>>> atomic_unsigned g_ver = 0;
>>>>>>>>>>
>>>>>>>>>> state g_state;
>>>>>>>>>>
>>>>>>>>>> // writers
>>>>>>>>>> lock(g_lock);
>>>>>>>>>>    ++ver;
>>>>>>>>>>
>>>>>>>>>>      ++g_state.a;
>>>>>>>>>>
>>>>>>>>>>    ++ver;
>>>>>>>>>> unlock(g_lock);
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> // readers
>>>>>>>>>> state lstate;
>>>>>>>>>>
>>>>>>>>>> for (;;)
>>>>>>>>>> {
>>>>>>>>>>    unsigned ver0 = g_ver;
>>>>>>>>>>
>>>>>>>>>>      lstate = g_state;
>>>>>>>>>>
>>>>>>>>>>    unsigned ver1 = g_ver;
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    if ((! (ver0 & 1)) && (ver0 == ver1))
>>>>>>>>>>    {
>>>>>>>>>>       break;
>>>>>>>>>>    }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    // A reader spun! Humm...
>>>>>>>>>>    // yield, backoff, do something else
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The pattern is read-mostly, write-rarely. Fast reads, slow
>>>>>>>>>> writes. It works in user-land.
>>>>>>>>>
>>>>>>>>> Boy, you're so ultimately studpid.
>>>>>>>>>
>>>>>>>>> Readers could spin for a long time when whe writer is scheduled
>>>>>>>>> away. So the approach of 1024 cores is not tolerable in userspace
>>>>>>>>> and seqlocks only make sense in kernel space where the writer
>>>>>>>>> could
>>>>>>>>> disable scheduling while spinning of modifying.
>>>>>>>>
>>>>>>>> A writer never spins! God damn it. LOL!
>>>>>>>
>>>>>>> With this stupid 1024 cores implementation not.
>>>>>>
>>>>>> Huh? A traditional seqlock uses a lock for a writer. You really
>>>>>> need to calm down and read about seqlocks.
>>>>>
>>>>> That's linux seqlock-structure:
>>>>>
>>>>> typedef struct {
>>>>>      struct seqcount seqcount;
>>>>>      spinlock_t lock;
>>>>> } seqlock_t;
>>>>>
>>>>> Where's the mutex ?
>>>>
>>>> Humm... I am going to guess that the spinlock_t is the mutual
>>>> exclusion lock here. LOL! Are you kidding me?
>>>
>>> spinlock_t is a spinlock, and not a mutex.
>>> Linux kernel seqlocks don't include a mutex.
>>
>> Using a mutex in user land is fine! Using a seqlock with a mutex in
>> userland is fine as long as your usage pattern fits in with
>> read-mostly, write rarely.
>
> Using mutexes for "seqlocks" on the writer-side doesn't preserve the
> readers from spinning. So seqlocks in user-space implmented in that
> way are a strupid idea.
>

Am 02.03.2022 um 06:33 schrieb Chris M. Thomasson:
> On 3/1/2022 9:25 PM, Bonita Montero wrote:
>> Am 02.03.2022 um 06:21 schrieb Chris M. Thomasson:
>>> On 3/1/2022 9:12 PM, Bonita Montero wrote:
>>>> Am 02.03.2022 um 06:10 schrieb Chris M. Thomasson:
>>>>> On 3/1/2022 9:09 PM, Bonita Montero wrote:
>>>>>> Am 02.03.2022 um 06:05 schrieb Chris M. Thomasson:
>>>>>>> On 3/1/2022 9:02 PM, Bonita Montero wrote:
>>>>>>>> Am 02.03.2022 um 05:50 schrieb Chris M. Thomasson:
>>>>>>>>> On 3/1/2022 8:40 PM, Bonita Montero wrote:
>>>>>>>>>> Am 02.03.2022 um 05:29 schrieb Chris M. Thomasson:
>>>>>>>>>>> On 3/1/2022 8:12 PM, Bonita Montero wrote:
>>>>>>>>>>>> Am 02.03.2022 um 04:54 schrieb Chris M. Thomasson:
>>>>>>>>>>>>> On 3/1/2022 7:45 PM, Bonita Montero wrote:
>>>>>>>>>>>>>> Am 01.03.2022 um 22:32 schrieb Chris M. Thomasson:
>>>>>>>>>>>>>>> On 2/28/2022 11:51 PM, Bonita Montero wrote:
>>>>>>>>>>>>>>>> Am 28.02.2022 um 01:14 schrieb Chris M. Thomasson:
>>>>>>>>>>>>>>>>> On 2/27/2022 2:35 PM, das...@gmail.com wrote:
>>>>>>>>>>>>>>>>>> I have 3 variables used as interface variables between
>>>>>>>>>>>>>>>>>> 2 threads. Thread A writes the variables, and Thread B
>>>>>>>>>>>>>>>>>> reads them.  Let me call them v1, v2, and v3.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I buffer (or snapshot) them into local variables.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Question:  Do the local variables need to be declared
>>>>>>>>>>>>>>>>>> volatile as well?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The local variables are fine, and do not need to be
>>>>>>>>>>>>>>>>> atomic/volatile, ect... Btw, think about using C
>>>>>>>>>>>>>>>>> atomic's instead of volatile. You might be interested
>>>>>>>>>>>>>>>>> in a seqlock:
>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Seqlock
>>>>>>>>>>>>>>>>> (read all)
>>>>>>>>>>>>>>>>> They are geared to a read-mostly, write rarely pattern.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Seqlocks don't make sense in user-space as they're
>>>>>>>>>>>>>>>> lock-free and
>>>>>>>>>>>>>>>> a writer, having made the seq-counter odd, may be easily
>>>>>>>>>>>>>>>> scheduled
>>>>>>>>>>>>>>>> away before making the seq-counter even again.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Huh? The writers use a mutex. So, how lock-free is a writer?
>>>>>>>>>>>>>>> For some reason, I don't think you have ever used one.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Seqlocks need disabling the scheduler on a core while writing
>>>>>>>>>>>>>> that a writer can't be scheduled away. That's not possible in
>>>>>>>>>>>>>> user-mode.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Huh? Wow. This basically confirms that you have never used
>>>>>>>>>>>>> a seqlock in user land. Remember that the writer uses a
>>>>>>>>>>>>> normal mutex. Now, a friend of mine created a really neat
>>>>>>>>>>>>> mutation of a seqlock:
>>>>>>>>>>>>
>>>>>>>>>>>> No, readers and writers spin.
>>>>>>>>>>>> Otherwise you don't have a seq-lock but sth. different.
>>>>>>>>>>>> Look how it is implemented in the Linux kernel.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The basic seqlock minus the tricky membars:
>>>>>>>>>>>
>>>>>>>>>>> // quick and crude pseudo-code
>>>>>>>>>>>
>>>>>>>>>>> struct state { int a = 0; }
>>>>>>>>>>> mutex g_lock;
>>>>>>>>>>> atomic_unsigned g_ver = 0;
>>>>>>>>>>>
>>>>>>>>>>> state g_state;
>>>>>>>>>>>
>>>>>>>>>>> // writers
>>>>>>>>>>> lock(g_lock);
>>>>>>>>>>>    ++ver;
>>>>>>>>>>>
>>>>>>>>>>>      ++g_state.a;
>>>>>>>>>>>
>>>>>>>>>>>    ++ver;
>>>>>>>>>>> unlock(g_lock);
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> // readers
>>>>>>>>>>> state lstate;
>>>>>>>>>>>
>>>>>>>>>>> for (;;)
>>>>>>>>>>> {
>>>>>>>>>>>    unsigned ver0 = g_ver;
>>>>>>>>>>>
>>>>>>>>>>>      lstate = g_state;
>>>>>>>>>>>
>>>>>>>>>>>    unsigned ver1 = g_ver;
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>    if ((! (ver0 & 1)) && (ver0 == ver1))
>>>>>>>>>>>    {
>>>>>>>>>>>       break;
>>>>>>>>>>>    }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>    // A reader spun! Humm...
>>>>>>>>>>>    // yield, backoff, do something else
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The pattern is read-mostly, write-rarely. Fast reads, slow
>>>>>>>>>>> writes. It works in user-land.
>>>>>>>>>>
>>>>>>>>>> Boy, you're so ultimately studpid.
>>>>>>>>>>
>>>>>>>>>> Readers could spin for a long time when whe writer is scheduled
>>>>>>>>>> away. So the approach of 1024 cores is not tolerable in userspace
>>>>>>>>>> and seqlocks only make sense in kernel space where the writer
>>>>>>>>>> could
>>>>>>>>>> disable scheduling while spinning of modifying.
>>>>>>>>>
>>>>>>>>> A writer never spins! God damn it. LOL!
>>>>>>>>
>>>>>>>> With this stupid 1024 cores implementation not.
>>>>>>>
>>>>>>> Huh? A traditional seqlock uses a lock for a writer. You really
>>>>>>> need to calm down and read about seqlocks.
>>>>>>
>>>>>> That's linux seqlock-structure:
>>>>>>
>>>>>> typedef struct {
>>>>>>      struct seqcount seqcount;
>>>>>>      spinlock_t lock;
>>>>>> } seqlock_t;
>>>>>>
>>>>>> Where's the mutex ?
>>>>>
>>>>> Humm... I am going to guess that the spinlock_t is the mutual
>>>>> exclusion lock here. LOL! Are you kidding me?
>>>>
>>>> spinlock_t is a spinlock, and not a mutex.
>>>> Linux kernel seqlocks don't include a mutex.
>>>
>>> Using a mutex in user land is fine! Using a seqlock with a mutex in
>>> userland is fine as long as your usage pattern fits in with
>>> read-mostly, write rarely.
>>
>> Using mutexes for "seqlocks" on the writer-side doesn't preserve the
>> readers from spinning. So seqlocks in user-space implmented in that
>> way are a strupid idea.
>>
>
> If course it does not prevent the readers from spinning. The readers
> can spin in the kernel as well. That's why the version count is there.

On 3/1/2022 9:39 PM, Bonita Montero wrote:
> Am 02.03.2022 um 06:33 schrieb Chris M. Thomasson:
>> On 3/1/2022 9:25 PM, Bonita Montero wrote:
>>> Am 02.03.2022 um 06:21 schrieb Chris M. Thomasson:
>>>> On 3/1/2022 9:12 PM, Bonita Montero wrote:
>>>>> Am 02.03.2022 um 06:10 schrieb Chris M. Thomasson:
>>>>>> On 3/1/2022 9:09 PM, Bonita Montero wrote:
>>>>>>> Am 02.03.2022 um 06:05 schrieb Chris M. Thomasson:
>>>>>>>> On 3/1/2022 9:02 PM, Bonita Montero wrote:
>>>>>>>>> Am 02.03.2022 um 05:50 schrieb Chris M. Thomasson:
>>>>>>>>>> On 3/1/2022 8:40 PM, Bonita Montero wrote:
>>>>>>>>>>> Am 02.03.2022 um 05:29 schrieb Chris M. Thomasson:
>>>>>>>>>>>> On 3/1/2022 8:12 PM, Bonita Montero wrote:
>>>>>>>>>>>>> Am 02.03.2022 um 04:54 schrieb Chris M. Thomasson:
>>>>>>>>>>>>>> On 3/1/2022 7:45 PM, Bonita Montero wrote:
>>>>>>>>>>>>>>> Am 01.03.2022 um 22:32 schrieb Chris M. Thomasson:
>>>>>>>>>>>>>>>> On 2/28/2022 11:51 PM, Bonita Montero wrote:
>>>>>>>>>>>>>>>>> Am 28.02.2022 um 01:14 schrieb Chris M. Thomasson:
>>>>>>>>>>>>>>>>>> On 2/27/2022 2:35 PM, das...@gmail.com wrote:
>>>>>>>>>>>>>>>>>>> I have 3 variables used as interface variables
>>>>>>>>>>>>>>>>>>> between 2 threads. Thread A writes the variables, and
>>>>>>>>>>>>>>>>>>> Thread B reads them.  Let me call them v1, v2, and v3.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I buffer (or snapshot) them into local variables.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Question:  Do the local variables need to be declared
>>>>>>>>>>>>>>>>>>> volatile as well?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The local variables are fine, and do not need to be
>>>>>>>>>>>>>>>>>> atomic/volatile, ect... Btw, think about using C
>>>>>>>>>>>>>>>>>> atomic's instead of volatile. You might be interested
>>>>>>>>>>>>>>>>>> in a seqlock:
>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Seqlock
>>>>>>>>>>>>>>>>>> (read all)
>>>>>>>>>>>>>>>>>> They are geared to a read-mostly, write rarely pattern.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Seqlocks don't make sense in user-space as they're
>>>>>>>>>>>>>>>>> lock-free and
>>>>>>>>>>>>>>>>> a writer, having made the seq-counter odd, may be
>>>>>>>>>>>>>>>>> easily scheduled
>>>>>>>>>>>>>>>>> away before making the seq-counter even again.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Huh? The writers use a mutex. So, how lock-free is a
>>>>>>>>>>>>>>>> writer?
>>>>>>>>>>>>>>>> For some reason, I don't think you have ever used one.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Seqlocks need disabling the scheduler on a core while
>>>>>>>>>>>>>>> writing
>>>>>>>>>>>>>>> that a writer can't be scheduled away. That's not
>>>>>>>>>>>>>>> possible in
>>>>>>>>>>>>>>> user-mode.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Huh? Wow. This basically confirms that you have never used
>>>>>>>>>>>>>> a seqlock in user land. Remember that the writer uses a
>>>>>>>>>>>>>> normal mutex. Now, a friend of mine created a really neat
>>>>>>>>>>>>>> mutation of a seqlock:
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, readers and writers spin.
>>>>>>>>>>>>> Otherwise you don't have a seq-lock but sth. different.
>>>>>>>>>>>>> Look how it is implemented in the Linux kernel.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The basic seqlock minus the tricky membars:
>>>>>>>>>>>>
>>>>>>>>>>>> // quick and crude pseudo-code
>>>>>>>>>>>>
>>>>>>>>>>>> struct state { int a = 0; }
>>>>>>>>>>>> mutex g_lock;
>>>>>>>>>>>> atomic_unsigned g_ver = 0;
>>>>>>>>>>>>
>>>>>>>>>>>> state g_state;
>>>>>>>>>>>>
>>>>>>>>>>>> // writers
>>>>>>>>>>>> lock(g_lock);
>>>>>>>>>>>>    ++ver;
>>>>>>>>>>>>
>>>>>>>>>>>>      ++g_state.a;
>>>>>>>>>>>>
>>>>>>>>>>>>    ++ver;
>>>>>>>>>>>> unlock(g_lock);
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> // readers
>>>>>>>>>>>> state lstate;
>>>>>>>>>>>>
>>>>>>>>>>>> for (;;)
>>>>>>>>>>>> {
>>>>>>>>>>>>    unsigned ver0 = g_ver;
>>>>>>>>>>>>
>>>>>>>>>>>>      lstate = g_state;
>>>>>>>>>>>>
>>>>>>>>>>>>    unsigned ver1 = g_ver;
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>    if ((! (ver0 & 1)) && (ver0 == ver1))
>>>>>>>>>>>>    {
>>>>>>>>>>>>       break;
>>>>>>>>>>>>    }
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>    // A reader spun! Humm...
>>>>>>>>>>>>    // yield, backoff, do something else
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The pattern is read-mostly, write-rarely. Fast reads, slow
>>>>>>>>>>>> writes. It works in user-land.
>>>>>>>>>>>
>>>>>>>>>>> Boy, you're so ultimately studpid.
>>>>>>>>>>>
>>>>>>>>>>> Readers could spin for a long time when whe writer is scheduled
>>>>>>>>>>> away. So the approach of 1024 cores is not tolerable in
>>>>>>>>>>> userspace
>>>>>>>>>>> and seqlocks only make sense in kernel space where the writer
>>>>>>>>>>> could
>>>>>>>>>>> disable scheduling while spinning of modifying.
>>>>>>>>>>
>>>>>>>>>> A writer never spins! God damn it. LOL!
>>>>>>>>>
>>>>>>>>> With this stupid 1024 cores implementation not.
>>>>>>>>
>>>>>>>> Huh? A traditional seqlock uses a lock for a writer. You really
>>>>>>>> need to calm down and read about seqlocks.
>>>>>>>
>>>>>>> That's linux seqlock-structure:
>>>>>>>
>>>>>>> typedef struct {
>>>>>>>      struct seqcount seqcount;
>>>>>>>      spinlock_t lock;
>>>>>>> } seqlock_t;
>>>>>>>
>>>>>>> Where's the mutex ?
>>>>>>
>>>>>> Humm... I am going to guess that the spinlock_t is the mutual
>>>>>> exclusion lock here. LOL! Are you kidding me?
>>>>>
>>>>> spinlock_t is a spinlock, and not a mutex.
>>>>> Linux kernel seqlocks don't include a mutex.
>>>>
>>>> Using a mutex in user land is fine! Using a seqlock with a mutex in
>>>> userland is fine as long as your usage pattern fits in with
>>>> read-mostly, write rarely.
>>>
>>> Using mutexes for "seqlocks" on the writer-side doesn't preserve the
>>> readers from spinning. So seqlocks in user-space implmented in that
>>> way are a strupid idea.
>>>
>>
>> If course it does not prevent the readers from spinning. The readers
>> can spin in the kernel as well. That's why the version count is there.
>
> *facepalm*
>
> Going to the kernel with a userland seqlock doesn't make it a seqlock
> any more.
> Seqlocks aren't possible in userspace. Spinning for a writer being
> scheduled away isn't tolerable. That's while seqlock inside th kernel
> disable the scheduler for a short while (by disabling interrupts) so
> that the readers always wait for the seqlock a very short time.

> A seqlock in userland works fine. ...

Seqlocks in userspace a are a stupid idea. Having a writer that
can be scheduled away and thereby keep spinning a readers for a
long time isn't tolerable.

On 3/1/2022 8:29 PM, Chris M. Thomasson wrote:
> On 3/1/2022 8:12 PM, Bonita Montero wrote:
>> Am 02.03.2022 um 04:54 schrieb Chris M. Thomasson:
>>> On 3/1/2022 7:45 PM, Bonita Montero wrote:
>>>> Am 01.03.2022 um 22:32 schrieb Chris M. Thomasson:
>>>>> On 2/28/2022 11:51 PM, Bonita Montero wrote:
>>>>>> Am 28.02.2022 um 01:14 schrieb Chris M. Thomasson:
>>>>>>> On 2/27/2022 2:35 PM, das...@gmail.com wrote:
>>>>>>>> I have 3 variables used as interface variables between 2
>>>>>>>> threads. Thread A writes the variables, and Thread B reads
>>>>>>>> them.  Let me call them v1, v2, and v3.
>>>>>>>>
>>>>>>>> I buffer (or snapshot) them into local variables.
>>>>>>>>
>>>>>>>> Question:  Do the local variables need to be declared volatile
>>>>>>>> as well?
>>>>>>>
>>>>>>> The local variables are fine, and do not need to be
>>>>>>> atomic/volatile, ect... Btw, think about using C atomic's instead
>>>>>>> of volatile. You might be interested in a seqlock:
>>>>>>> https://en.wikipedia.org/wiki/Seqlock
>>>>>>> (read all)
>>>>>>> They are geared to a read-mostly, write rarely pattern.
>>>>>>
>>>>>> Seqlocks don't make sense in user-space as they're lock-free and
>>>>>> a writer, having made the seq-counter odd, may be easily scheduled
>>>>>> away before making the seq-counter even again.
>>>>>
>>>>> Huh? The writers use a mutex. So, how lock-free is a writer?
>>>>> For some reason, I don't think you have ever used one.
>>>>
>>>> Seqlocks need disabling the scheduler on a core while writing
>>>> that a writer can't be scheduled away. That's not possible in
>>>> user-mode.
>>>
>>> Huh? Wow. This basically confirms that you have never used a seqlock
>>> in user land. Remember that the writer uses a normal mutex. Now, a
>>> friend of mine created a really neat mutation of a seqlock:
>>
>> No, readers and writers spin.
>> Otherwise you don't have a seq-lock but sth. different.
>> Look how it is implemented in the Linux kernel.
>
>
> The basic seqlock minus the tricky membars:
>
> // quick and crude pseudo-code
>
> struct state { int a = 0; }
> mutex g_lock;
> atomic_unsigned g_ver = 0;
>
> state g_state;
>
> // writers
> lock(g_lock);
>   ++ver;
>
>     ++g_state.a;
>
>   ++ver;
> unlock(g_lock);
>
>
> // readers
> state lstate;
>

// ARGH!!!
____________________
> for (;;)
> {
>   unsigned ver0 = g_ver;
>
>     lstate = g_state;
>
>   unsigned ver1 = g_ver;
>
>
>   if ((! (ver0 & 1)) && (ver0 == ver1))
>   {
>      break;
>   }
>
>
>   // A reader spun! Humm...
>   // yield, backoff, do something else
> }
____________________

That should be:

____________________
for (;;)
{ unsigned ver0 = g_ver;

if (ver0 & 1)
{
// we spun on a locked state
continue;
}

lstate = g_state;

unsigned ver1 = g_ver;

if (ver0 == ver1)
{
break;
}

// A reader spun because the data was changed!
// Humm...
// yield, backoff, do something else
} ____________________

Sorry about that crap. That's what I get for quickly typing it out in
the damn newsreader. ;^o

>
> The pattern is read-mostly, write-rarely. Fast reads, slow writes. It
> works in user-land.

> Sorry about that crap. That's what I get for quickly typing it out in
> the damn newsreader. ;^o

No matter which implementation you chose - seqlocks in userspace
don't make any sense.

On 3/1/2022 9:52 PM, Bonita Montero wrote:
>> A seqlock in userland works fine. ...
>
> Seqlocks in userspace a are a stupid idea. Having a writer that
> can be scheduled away and thereby keep spinning a readers for a
> long time isn't tolerable.
>

Fwiw, I wrote a little experiment over on comp.lang.c++:

https://groups.google.com/g/comp.lang.c++/c/RYASx2cGqes/m/Cwv2WtG3BAAJ