I'm looking for confirmation on a couple questions regarding accessing shared variables (C SDK, both rp2040 and 235x). I found a few threads touching on the subject but not quite answering these. I have my own idea of what the answers are, but I'll phrase these as questions first:
Say we have a program roughly like this:So basically core0 is writing to the shared 32-bit variable and core1 is reading the value of said variable at random instants. No mutexes or any kind of synchronization between the cores is employed.
Is it possible for:
1. "result" to ever take on any value other than the values written by core0 (VAL_A or VAL_B) ?
2. Something bad to happen if core1 happens to read the shared variable during the same clock cycle that core0 writes to said variable
3. The answer to 1) or 2) to change if the shared variable is of a different type (32-bit or less, e.g. float, uint8_t, bool etc.)
My assumption is no to all three points.
To take this a little a little further, we could also have a scenario where both cores read the shared variable or write to it simultaneously. Is it possible for some sort of race condition to occur in any case? Or for the read value of the shared variable to be anything other than the full 32-bits written to it by core0 or core1?
My assumption to the above is again no, since the full 32-bits are written in one clock cycle and simultaneous access to the variable will result in the higher priority core being granted access first, followed by the lower priority core, meaning they access the location in sram one after the other and never actually simultaneously, be it a read or write operation. Thus doing all of the above would be safe. Am I wrong?
Say we have a program roughly like this:
Code:
volatile uint32_t shared_var = VAL_A;core0(){while(1){if(shared_var == VAL_A){shared_var = VAL_B;}else{shared_var = VAL_A;}}}core1(){while(1){uint32_t result = shared_var;do_something_else_for_random_number_of_cycles();}}Is it possible for:
1. "result" to ever take on any value other than the values written by core0 (VAL_A or VAL_B) ?
2. Something bad to happen if core1 happens to read the shared variable during the same clock cycle that core0 writes to said variable
3. The answer to 1) or 2) to change if the shared variable is of a different type (32-bit or less, e.g. float, uint8_t, bool etc.)
My assumption is no to all three points.
To take this a little a little further, we could also have a scenario where both cores read the shared variable or write to it simultaneously. Is it possible for some sort of race condition to occur in any case? Or for the read value of the shared variable to be anything other than the full 32-bits written to it by core0 or core1?
My assumption to the above is again no, since the full 32-bits are written in one clock cycle and simultaneous access to the variable will result in the higher priority core being granted access first, followed by the lower priority core, meaning they access the location in sram one after the other and never actually simultaneously, be it a read or write operation. Thus doing all of the above would be safe. Am I wrong?
Statistics: Posted by Transonic — Mon Nov 04, 2024 5:26 pm