[chbot] Chchrobotics Digest, Vol 173, Issue 5

[Bevin Brett]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/chchrobotics/attachments/20220206/2990f615/attachment.html>