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?

Thanks, Dave A.

Code below.

-----

volatile int v1;
volatile int v2;
volatile int v3;

void ThreadA(void) //Writes the variables.
{ //3 critical sections, but doesn't matter if ThreadB()
//obtains values not obtained at exactly the same
//time.
...
MUTEX_BEGIN();
v1 = expression1;
MUTEX_END();
...
MUTEX_BEGIN();
v2 = expression2;
MUTEX_END();
...
MUTEX_BEGIN();
v3 = expression3;
MUTEX_END();
}

void ThreadB(void) //Reads/uses the variables.
{ /* volatile???? */ int buf_v1, buf_v2, buf_v3;
//My Question: Is there any necessity to declare the 3
//buffer variables above volatile, or does the
//"sequence point" behavior of volatile v1, v2, and v3
//provide a strong enough guarantee? In other words,
//are buf_v1, buf_v2, and buf_v3 guaranteed assigned
//before MUTEX_END()?
...
MUTEX_BEGIN();
buf_v1 = v1;
buf_v2 = v2;
buf_v3 = v3;
MUTEX_END();

...
... //Miscellaneous tests and reads involving
... //buf_v1, buf_v2, and buf_v3.
...
}

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.

On 2/27/2022 11: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?
>
> Thanks, Dave A.
>
> Code below.
>
> -----
>
> volatile int v1;
> volatile int v2;
> volatile int v3;
>
> void ThreadA(void) //Writes the variables.
> {
> //3 critical sections, but doesn't matter if ThreadB()
> //obtains values not obtained at exactly the same
> //time.
> ...
> MUTEX_BEGIN();
> v1 = expression1;
> MUTEX_END();
> ...
> MUTEX_BEGIN();
> v2 = expression2;
> MUTEX_END();
> ...
> MUTEX_BEGIN();
> v3 = expression3;
> MUTEX_END();
> }
>
> void ThreadB(void) //Reads/uses the variables.
> {
> /* volatile???? */ int buf_v1, buf_v2, buf_v3;
> //My Question: Is there any necessity to declare the 3
> //buffer variables above volatile, or does the
> //"sequence point" behavior of volatile v1, v2, and v3
> //provide a strong enough guarantee? In other words,
> //are buf_v1, buf_v2, and buf_v3 guaranteed assigned
> //before MUTEX_END()?
> ...
> MUTEX_BEGIN();
> buf_v1 = v1;
> buf_v2 = v2;
> buf_v3 = v3;
> MUTEX_END();
>
> ...
> ... //Miscellaneous tests and reads involving
> ... //buf_v1, buf_v2, and buf_v3.
> ...
> }

I'm not a fan of this use of volatile[*], and as a consequence I am not
that much of an expert either, however:

1) The buf_v1/v2/v3 variables need not be volatile, since both read and
write access to v1/v2/v3 is protected by memory barriers due to their
volatile qualifiers.

2) If you synchronize access to v1/v2/v3 with mutexes you don't need to
make them volatile either.

[*] the volatile keyword was introduced in C for a somewhat different
purpose than multithreaded access, although it may work for this purpose
too under some conditions.
The proper way to handle multithreaded read/write is atomics in modern
C, or locking (mutexes etc.)

On 2/27/2022 4:26 PM, Manfred wrote:
> On 2/27/2022 11: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?
>>
>> Thanks, Dave A.
>>
>> Code below.
>>
>> -----
>>
>> volatile int v1;
>> volatile int v2;
>> volatile int v3;
>>
>> void ThreadA(void)  //Writes the variables.
>> {
>>     //3 critical sections, but doesn't matter if ThreadB()
>>     //obtains values not obtained at exactly the same
>>     //time.
>>     ...
>>     MUTEX_BEGIN();
>>     v1 = expression1;
>>     MUTEX_END();
>>     ...
>>     MUTEX_BEGIN();
>>     v2 = expression2;
>>     MUTEX_END();
>>     ...
>>     MUTEX_BEGIN();
>>     v3 = expression3;
>>     MUTEX_END();
>> }
>>
>> void ThreadB(void)  //Reads/uses the variables.
>> {
>>     /* volatile???? */ int buf_v1, buf_v2, buf_v3;
>>     //My Question:  Is there any necessity to declare the 3
>>     //buffer variables above volatile, or does the
>>     //"sequence point" behavior of volatile v1, v2, and v3
>>     //provide a strong enough guarantee?  In other words,
>>     //are buf_v1, buf_v2, and buf_v3 guaranteed assigned
>>     //before MUTEX_END()?
>>     ...
>>     MUTEX_BEGIN();
>>     buf_v1 = v1;
>>     buf_v2 = v2;
>>     buf_v3 = v3;
>>     MUTEX_END();
>>
>>     ...
>>     ... //Miscellaneous tests and reads involving
>>     ... //buf_v1, buf_v2, and buf_v3.
>>     ...
>> }
>
> I'm not a fan of this use of volatile[*], and as a consequence I am not
> that much of an expert either, however:
>
> 1) The buf_v1/v2/v3 variables need not be volatile, since both read and
> write access to v1/v2/v3 is protected by memory barriers due to their
> volatile qualifiers.
>
> 2) If you synchronize access to v1/v2/v3 with mutexes you don't need to
> make them volatile either.
>
> [*] the volatile keyword was introduced in C for a somewhat different
> purpose than multithreaded access, although it may work for this purpose
> too under some conditions.
> The proper way to handle multithreaded read/write is atomics in modern
> C, or locking (mutexes etc.)

Think of the following scenario:

// pseudo code
_____________________________
atomic_int g_a = 0;
atomic_int g_b = 0;
atomic_int g_c = 0;

mtx_t g_lock;

void thread_a()
{ mtx_lock(&g_lock);
g_b = g_b + 1;
mtx_unlock(&g_lock);
}

void thread_b()
{ mtx_lock(&g_lock);
int a = atomic_load(&g_a, memory_order_relaxed);
mtx_unlock(&g_lock);
} _____________________________

Now, even though thread_b is acquiring the mutex, it still reads g_a
outside of mutex protection. This can be an interesting situation
because if thread_a decided to alter g_a outside of mutex protection,
then g_a needs to be atomic. So, to get at the bare bones wrt the
pseudo-code I posted:
_____________________________

atomic_int g_a = 0;
int g_b = 0;
int g_c = 0;

mtx_t g_lock;

void thread_a()
{ mtx_lock(&g_lock);
g_b = g_b + 1;
mtx_unlock(&g_lock);
}

void thread_b()
{ mtx_lock(&g_lock);
int a = atomic_load(&g_a, memory_order_relaxed);
int b = g_b; // does not need to be atomic.
mtx_unlock(&g_lock);
} _____________________________

This works fine, as long as you are not dependent on any external data
wrt g_a. Then, an acquire might be in order wrt loading from g_a.

Iirc volatile does not guarantee anything wrt memory visibility. Use C
atomics.

On 27/02/2022 23:35, 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?
>
> Thanks, Dave A.
>
> Code below.

To understand "volatile", you should think in terms of volatile
/accesses/, not volatile /objects/. Think of an object that is declared
"volatile" as simply being one for which all accesses must be volatile.

You also need to understand that the compiler sees the generated object
as a sequence of instructions - it knows nothing about hardware
instruction scheduling, out-of-order execution, speculative execution,
read-ahead, write buffers, caches, multiple cores, or anything else.
Keep that in mind for these next few paragraphs.

A "volatile" access is observable behaviour - the compiler can't omit
it, add new ones, combine them or re-order them. So it gives an
ordering amongst other volatile accesses (and other observable behaviour
such as file I/O, or things that /might/ have observable behaviour such
as calling a function the compiler knows nothing about).

When you have :

volatile int v1, v2;

then
buf_v1 = v1;
buf_v2 = v2;

the compiler must generate an instruction to read "v1", and an
instruction to read "v2". The read of "v1" must come first, and there
can be no duplicate reads, or re-ordering with other volatile accesses.
What happens with the values it reads does not really matter. They can
be put in registers, or memory, or manipulated or thrown away. Since
"buf_v1" and "buf_v2" are not part of your interface, you don't care how
they are used at the low level. So there is no benefit in making them
"volatile".

If your program is to run on a target with a simple execution model -
with the key point being a single processor core - then you can use
"volatile" data like this. This is common in small-systems embedded
programming on microcontrollers. But obviously it does not apply to
anything on a bigger processor with more than one core - PC's, embedded
Linux, etc.

On a single-core processor you only need a mutex if you need atomic
consistency that is wider than the single-instruction access width for
the processor. Thus you don't need a mutex at all if the three
variables are independent (assuming your processor can handle an "int"
read or write in a single instruction).

If your program is running on a multi-core system, things get a /lot/
more complicated. Within a thread, the program will see volatile
accesses in the order the compiler generated them. But across threads,
which might be running on different cores, you have no such guarantees.
Volatile writes from one thread might never be seen at all on other
threads. So you need stronger controls that handle visibility across
threads, using atomics, fences, etc., and often you no longer need
"volatile" at all.

The best choice here can depend on the details of your tools, your
target, your OS. C11 atomics could be used, but only if you have C11
and good atomics support. Whatever implements "MUTEX_BEGIN" and
"MUTEX_END" might have support for other approaches.

On Monday, 28 February 2022 at 00:35:56 UTC+2, 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 volatile keyword doesn’t give the right kind of control for multi-processor
or multi-thread synchronisation generally. It is meant for something else.
But implementor of particular C compiler can of course add there whatever
additional meanings that standard does not require.

By standard the compiler is allowed to migrate non-volatile accesses
above or below a volatile access. The compiler is not required to insert
memory barriers around volatile accesses. When there are no memory
barriers then the hardware can reorder them with respect to non-volatile
accesses despite whatever compiler did. The hardware can even reorder
two volatile accesses if the memory attributes permit it.

Therefore your volatile usage is either pointless or platform-specific repair
of defects in undisclosed MUTEX_BEGIN() and MUTEX_END().

On Mon, 2022-02-28, ???? Tiib wrote:
> On Monday, 28 February 2022 at 00:35:56 UTC+2, 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?
....

> Therefore your volatile usage is either pointless or platform-specific repair
> of defects in undisclosed MUTEX_BEGIN() and MUTEX_END().

Yeah, /that/ was my take on the question: that it's impossible to say
anything without knowing what MUTEX_BEGIN/END means. Normally a mutex
is an object which you lock or unlock, so these BEGIN/END things look
odd, and hint at a misunderstanding of the concepts.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On 2022-02-28, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> On Mon, 2022-02-28, ???? Tiib wrote:
>> On Monday, 28 February 2022 at 00:35:56 UTC+2, 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?
> ...
>
>> Therefore your volatile usage is either pointless or platform-specific repair
>> of defects in undisclosed MUTEX_BEGIN() and MUTEX_END().
>
> Yeah, /that/ was my take on the question: that it's impossible to say
> anything without knowing what MUTEX_BEGIN/END means. Normally a mutex
> is an object which you lock or unlock, so these BEGIN/END things look
> odd, and hint at a misunderstanding of the concepts.

Mutexes protect critial regions of code, which begin and end.

"Mutually exclusive execution belongs here; ends here."

Makes sense.

Rather, what is strange is the "mutex" naming metonymy: the object used
for ensuring mutual exclusion is called "mutual exclusion".

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

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.

Am 27.02.2022 um 23:35 schrieb das...@gmail.com:
> 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?
>
> Thanks, Dave A.
>
> Code below.
>
> -----
>
> volatile int v1;
> volatile int v2;
> volatile int v3;
>
> void ThreadA(void) //Writes the variables.
> {
> //3 critical sections, but doesn't matter if ThreadB()
> //obtains values not obtained at exactly the same
> //time.
> ...
> MUTEX_BEGIN();
> v1 = expression1;
> MUTEX_END();
> ...
> MUTEX_BEGIN();
> v2 = expression2;
> MUTEX_END();
> ...
> MUTEX_BEGIN();
> v3 = expression3;
> MUTEX_END();
> }

If MUTEX_BEGIN() and MUTEX_END() include proper barriers
no volatile is needed.

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.

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.

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:

https://www.1024cores.net/home/lock-free-algorithms/reader-writer-problem/improved-lock-free-seqlock

Implementing a seqlock is tricky wrt proper memory visibility, but it
can be done in 100% pure C11.

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.

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.

Writers never spin. They use a lock. Read about the algorithm. Read it
again, and one more time.

Am 02.03.2022 um 05:17 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.
>
> Writers never spin. They use a lock. Read about the algorithm. Read it
> again, and one more time.

With seqlocks like in the kernel writer always spin.
Seqlocks inside the kernel never use a mutex.

And this seqlock-"implementation" on 1024 cores ist stupid.
With this implementation readers could spin for a long time
when a writer is scheduled away. That's not tolerable.

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.

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.

On 3/1/2022 8:28 PM, Bonita Montero wrote:
> Am 02.03.2022 um 05:17 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.
>>
>> Writers never spin. They use a lock. Read about the algorithm. Read it
>> again, and one more time.
>
> With seqlocks like in the kernel writer always spin.
> Seqlocks inside the kernel never use a mutex.
>
> And this seqlock-"implementation" on 1024 cores ist stupid.

You really think so? Wow.

> With this implementation readers could spin for a long time
> when a writer is scheduled away. That's not tolerable.

The readers can choose to spin, or do something else. Traditional
Seqlocks are really great in read-mostly, write rarely scenarios, yes in
user space. Btw, my friends impl heavily reduces reader spins if a lot
of writer activity suddenly occurs by heavily amortizing things. Keep in
mind of the usage pattern.

Am 02.03.2022 um 05:41 schrieb Chris M. Thomasson:
> On 3/1/2022 8:28 PM, Bonita Montero wrote:
>> Am 02.03.2022 um 05:17 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.
>>>
>>> Writers never spin. They use a lock. Read about the algorithm. Read
>>> it again, and one more time.
>>
>> With seqlocks like in the kernel writer always spin.
>> Seqlocks inside the kernel never use a mutex.
>>
>> And this seqlock-"implementation" on 1024 cores ist stupid.
>
> You really think so? Wow.

Yes, with that implementaiton a writer could be scheduled away
and a reader could spin for a long time.
Seqlocks inside the kernel don't use mutexes but disable the
scheduler for writers.

> The readers can choose to spin, or do something else. ..

Boy, you're so stupid.

On 3/1/2022 8:44 PM, Bonita Montero wrote:
> Am 02.03.2022 um 05:41 schrieb Chris M. Thomasson:
>> On 3/1/2022 8:28 PM, Bonita Montero wrote:
>>> Am 02.03.2022 um 05:17 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.
>>>>
>>>> Writers never spin. They use a lock. Read about the algorithm. Read
>>>> it again, and one more time.
>>>
>>> With seqlocks like in the kernel writer always spin.
>>> Seqlocks inside the kernel never use a mutex.
>>>
>>> And this seqlock-"implementation" on 1024 cores ist stupid.
>>
>> You really think so? Wow.
>
> Yes, with that implementaiton a writer could be scheduled away
> and a reader could spin for a long time.
> Seqlocks inside the kernel don't use mutexes but disable the
> scheduler for writers.
>
>> The readers can choose to spin, or do something else. ..
>
> Boy, you're so stupid.

Sigh. Yet another algorithm that you don't really know about. Just like
when you tried to say lock-free queues are useless. Many example of me
correcting you now.

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!

Am 02.03.2022 um 05:49 schrieb Chris M. Thomasson:
> On 3/1/2022 8:44 PM, Bonita Montero wrote:
>> Am 02.03.2022 um 05:41 schrieb Chris M. Thomasson:
>>> On 3/1/2022 8:28 PM, Bonita Montero wrote:
>>>> Am 02.03.2022 um 05:17 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.
>>>>>
>>>>> Writers never spin. They use a lock. Read about the algorithm. Read
>>>>> it again, and one more time.
>>>>
>>>> With seqlocks like in the kernel writer always spin.
>>>> Seqlocks inside the kernel never use a mutex.
>>>>
>>>> And this seqlock-"implementation" on 1024 cores ist stupid.
>>>
>>> You really think so? Wow.
>>
>> Yes, with that implementaiton a writer could be scheduled away
>> and a reader could spin for a long time.
>> Seqlocks inside the kernel don't use mutexes but disable the
>> scheduler for writers.
>>
>>> The readers can choose to spin, or do something else. ..
>>
>> Boy, you're so stupid.
>
> Sigh. Yet another algorithm that you don't really know about. Just like
> when you tried to say lock-free queues are useless. Many example of me
> correcting you now.

No one practically uses lock-free queues because they need spinning.

On 3/1/2022 12:23 AM, Bonita Montero wrote:
> Am 27.02.2022 um 23:35 schrieb das...@gmail.com:
>> 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?
>>
>> Thanks, Dave A.
>>
>> Code below.
>>
>> -----
>>
>> volatile int v1;
>> volatile int v2;
>> volatile int v3;
>>
>> void ThreadA(void)  //Writes the variables.
>> {
>>     //3 critical sections, but doesn't matter if ThreadB()
>>     //obtains values not obtained at exactly the same
>>     //time.
>>     ...
>>     MUTEX_BEGIN();
>>     v1 = expression1;
>>     MUTEX_END();
>>     ...
>>     MUTEX_BEGIN();
>>     v2 = expression2;
>>     MUTEX_END();
>>     ...
>>     MUTEX_BEGIN();
>>     v3 = expression3;
>>     MUTEX_END();
>> }
>
> If MUTEX_BEGIN() and MUTEX_END() include proper barriers
> no volatile is needed.
>

I think that is wrong Bonita. From what I can gather the following
scenario requires atomics and relaxed membars in the standard:

[0]: ThreadA: lock()
[1]: ThreadA: v1 = expression1;
[2]: ThreadA: unlock()
[3]: ThreadB: lock()
[4]: ThreadB: local_v2 = v2
[5]: ThreadB: unlock()

BAM! local_v2 just read v2 outside of the mutex protection. They need to
be atomic wrt the standard. relaxed membar can be used. I say this
because the OP did not fully explain what the expressions actually do. I
am assuming no data dependencies.

On 3/1/2022 9:01 PM, Bonita Montero wrote:
> Am 02.03.2022 um 05:49 schrieb Chris M. Thomasson:
>> On 3/1/2022 8:44 PM, Bonita Montero wrote:
>>> Am 02.03.2022 um 05:41 schrieb Chris M. Thomasson:
>>>> On 3/1/2022 8:28 PM, Bonita Montero wrote:
>>>>> Am 02.03.2022 um 05:17 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.
>>>>>>
>>>>>> Writers never spin. They use a lock. Read about the algorithm.
>>>>>> Read it again, and one more time.
>>>>>
>>>>> With seqlocks like in the kernel writer always spin.
>>>>> Seqlocks inside the kernel never use a mutex.
>>>>>
>>>>> And this seqlock-"implementation" on 1024 cores ist stupid.
>>>>
>>>> You really think so? Wow.
>>>
>>> Yes, with that implementaiton a writer could be scheduled away
>>> and a reader could spin for a long time.
>>> Seqlocks inside the kernel don't use mutexes but disable the
>>> scheduler for writers.
>>>
>>>> The readers can choose to spin, or do something else. ..
>>>
>>> Boy, you're so stupid.
>>
>> Sigh. Yet another algorithm that you don't really know about. Just
>> like when you tried to say lock-free queues are useless. Many example
>> of me correcting you now.
>
> No one practically uses lock-free queues because they need spinning.
>

Sigh.