это когда уже знаешь))

Изучил вопрос подробнее.
И, нет, volatile не нужен, если все доступы к переменной защищены мутексом (std::mutex), так как отпускание/взятие мутекса создаёт отношение synchronize-with, а оно в свою очередь порождает happens before. Таким образом все доступы к переменной упорядочены happens-before, а значит чтение переменной приведёт к чтению единственного видимого  значения [https://en.cppreference.com/w/cpp/atomic/memory_order раздел visible side effects]. Осталось понять, порождает ли взятие/отпускание бинарного семафора в rtos отношение synchronize-with.

да, часто не нужен. более того, часто даже вреден. но, иногда надо.

разве мьютекс гарантирует отсуствие оптимизаций связанных с чтением/записью переменных?

volatile не для синхронизации, и не для strict order. volatile для MMIO и иже с ними, когда компилятор не правильно понимает, с каких мест переменная может быть модифицированна

даже с мьютеском, но без volatile код:

*((u8_t*)0xdeadbeef) = 1;
*((u8_t*)0xdeadbeef) = 0;
*((u8_t*)0xdeadbeef) = 1;

заоптимизируется  в

*((u8_t*)0xdeadbeef) = 1;

Мютекс гарантирует что только один поток в определенный момент будет выполнять код им защищенный а если вы будете обращаться к переменной только в коде защищённом мютексом - то это будет гарантировать что к переменной больше никто в этот момент не обращается

от меня был риторический вопрос) я намекал на то, что volatile и мютексы - под разные (совсем) случаи

Тут согласен )

Он не гарантирует, что совсем никаких оптимизацией нет. Но он гарантирует, что все записи сделанные под мутексом в одном потоке, будут видны в другом. (я даже доказал это ссылками на memory model). Что касается оптимизаций: игры с компилятором в "угадай, что оптимизируется" никуда не приводят, потому что вы никогда не можете знать все оптимизации, которые умеет компилятор. В стандарте написано, что может вернуть чтение переменной, и при каких условиях оно гарантированно может вернуть только одно "последнее" записанное значение. Этим и надо пользоваться, а думать, что компилятор оптимизирует - это уже гадание.

во-первых у нас тут не stdc++, а bare metal С.
во-вторых ничего "взятие семафора в РТОС" не гарантирует, кроме как того, что написано в апи к этому РТОС.
во-третьих https://en.cppreference.com/w/c/language/volatile (читаем про observable side effects). happens-before тут ни к чему

хз как там в плюсах с 11го стандарта и далее, но в С модель строго однопоточная. компилятор не понимал, не понимает, и не будет понимать что такое потоки

Вот про гарантии семафора в RTOS - это открытый вопрос. Очень хотелось бы, чтобы там гарантировался synchronizes-with.

synchronized-with не существует как принципа, в Си.  откуда ему что-то там гарантировать?

В C не существует. А вот я использую RTOS из кода на C++17, и мне бы хотелось, чтобы в нём такая гарантия была при использовании FreeRTOS.

не будет. и я против. FreeRTOS на С и пускай такой и будет.

надо гарантии - пилите плз порт std под FreeRTOS, сообщите мне, я радостью воспользуюсь.

В тулчеине для esp32 есть std::mutex и даже std::thread, работающие поверх pthreads, которые в свою очередь поверх FreeRTOS. Слой совместимости с pthreads вот: https://github.com/espressif/esp-idf/blob/master/components/pthread/pthread.c . И забавно, что, в функциях блокировок/разблокировок никаких синхронизирующих действий, кроме взятия/освобождения семафора, там не делается. Так что, возможно, что и семафор FreeRTOS де-факто даёт такие гарантии.

вот кстати, не очень хороший код для демонстрации:

https://godbolt.org/z/4djTG6cjP

кстати, камень в мою сторону - если таки инициализировать поток (на none-eabi pthread_create() нет, на x86 видно), то С "понимает", что коллбек дернут, volatile не нужен.

не ожидал, что С++ спортирован на esp32)

На esp32 с этим всё замечательно. А вот на esp8266 у меня не удалось использовать даже std::optional.