[chbot] Chchrobotics Digest, Vol 173, Issue 5

[Paul Davey]

> 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

Indeed I suspect that in all likelihood the code was always invoking
undefined behaviour but the compiler previously never performed any
optimisations that happened to break this exact sequence, but the
newer compiler does.

On Sun, Feb 6, 2022 at 3:56 PM Simeon Pilgrim <simeon.pilgrim at gmail.com> wrote:
>
> 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.
>
> _______________________________________________
> 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.