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.