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.