[chbot] Chchrobotics Digest, Vol 173, Issue 5

[Simeon Pilgrim]

Nod, the volatile just means it can change by itself (which means there
might be other hardware setting it) thus the compiler should be read from
source each time it is used, verse poked into a register and kept locally,

or even more insidious read "early" and precomputed and just used "later".

But now that I type that last bit, this is exactly what the memory barriers
are then to force. an instruction to "read memory" can happen anytime prior
to "the line of code", and actually "any time prior to when the result is
used" (these are allowed by both  CPU and compiler) while volatile is just
a compiler thing. But also given the CPU has not changed, so we are really
looking at the level of aggression of the compiler. Slapping something like
full barrier `__sync_synchronize` in might help
https://stackoverflow.com/questions/19965076/gcc-memory-barrier-sync-synchronize-vs-asm-volatile-memory



On Sun, 6 Feb 2022 at 15:43, Bevin Brett <bevin_brett at hotmail.com> wrote:

> Assuming you are looking at a memory coherency issue, think of it like
> this...
>
> CPU0
>     cache0
>                          sharedMemory
>     cache1
> CPU1
>
> Your old code brought the volatile struct in from disk into cache0 a long
> time before it was used by CPU1.
>
>     struct inited into cache0 by disk read
>     ... long time elapses
>     cache0 version of struct gets flushed to sharedMemory
>     ... long time elapses
>     CPU0 tells CPU1 to use struct
>     CPU1 reads sharedMemory to get struct into cache1
>     CPU1 uses the values from struct
>
> Your new code does it MUCH later
>
>     struct inited into cache0 by instructions
>     *NOTHING FLUSHES* cache0 to sharedMemory
>     *ALMOST NO TIME ELAPSES*
>     CPU0 tells CPU1 to use struct
>     CPU1 reads sharedMemory to get struct into cache1
>     *PERHAPS A LONG TIME AFTER THAT READ* cache0 is flushed sharedMemory
>     CPU1 uses the values from the uninitialized values of struct
>
> or worse
>
>     struct inited into cache0 by instructions
>     *NOTHING FLUSHES* cache0 to sharedMemory
>     *ALMOST NO TIME ELAPSES*
>     CPU1 reads something near struct from sharedMemory getting the
> uninited struct into cache1
>     CPU0 tells CPU1 to use struct
>     CPU1 reads sharedMemory from cache1 getting an uninitialized struct
>     *PERHAPS A LONG TIME AFTER THAT READ* cache0 is flushed sharedMemory
>     CPU1 uses the values from the uninitialized values of struct
>
> Depending on the h/w, memory flushes may be needed to force the CPU0 to
> write the data to the shared memory, and memory barriers may be needed to
> stop CPU1 from reading the earlier versions of the data.
>
> As has been mentioned previously, volatile by itself does not necessarily
> cause these flushes and barriers to be needed
>
> _______________________________________________
> Chchrobotics mailing list Chchrobotics at lists.ourshack.com
> https://lists.ourshack.com/mailman/listinfo/chchrobotics
> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> Meetings usually 3rd Monday each month. See http://kiwibots.org for
> venue, directions and dates.
> When replying, please edit your Subject line to reflect new subjects.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/chchrobotics/attachments/20220206/19f41fbe/attachment.html>