ESP32 - does variable protected by mutex require volatile?

[smarq8]

Does xSemaphoreTake/Give() guarantee any variable to be updated in scenario of multiple core access? Or I need volatile or other things to do to ensure I will not read outdated content?

Code: Select all

uint32_t someVariable = 0; // should it be volatile?
void function(){
if(Mutex && xSemaphoreTake(Mutex,portMAX_DELAY)==pdTRUE){
// read/write someVariable here across both cores
xSemaphoreGive(Mutex);
}
}

[ESP_Sprite]

There's a long explanation that I could put here, but the 'plastered over' explanation is: no, it is not needed, and could actually stop the compiler from doing some optimizations. Volatile would be needed it you ran the code in a tight loop (e.g. 'while (variable) {}') as the compiler sees no way the variable could ever change and as such optimizes away the while loop. In your case, the xSemaphoreTake() function call makes the compiler assume that any variable could have changed (because, who knows, xSemaphoreTake could be a function that touches someVariable itself, for all the compiler knows), and someVariable will be read correctly.

(The details I plastered over are related to the memory model the ESP32 hardware uses; while it has a very simple cache that effectively is sequentially consistent, the Xtensa does have a single store buffer it can use, making the memory model more akin to TSO. This has technical implications if you want to go deep down the rabbit hole, but for your average embedded programmer, the effects of this are not really important.)

[smarq8]

Thank you for your reply.

What about scenario where I write protecting by mutex and read without mutex? Will it still work without volatile at reading assuming my variable is uint32_t memory aligned?
I just write some FIFO where uint32_t store two variables uint16_t just for ensure at least atomic read, it allow me to prevent use additional mutex at read necessary variables. After many tweaks I ensured read and write is single operation from disassembly.
I know volatile or nonvolatile variable does not break my target performance, Im just curios how should I consider similar scenario in future.

[ESP_Sprite]

That would also work. I'm decently sure it would work with the current SDK/silicon by simply defining the variable as an uint32_t or something, but for full portability you could also use C atomics to modify the value.