[ изменить]. Для чтения в фоновом режиме и для ясности это то, о чем я говорю: Введение в ключевое слово volatile
При анализе кода встроенных систем одной из наиболее распространенных ошибок, которые я вижу, является отсутствие волатильных данных для потоков данных/прерываний. Однако мой вопрос заключается в том, является ли "безопасным" не использовать volatile при доступе к переменной через функцию доступа или функцию-член?
Простой пример; в следующем коде...
volatile bool flag = false ;
void ThreadA()
{
...
while (!flag)
{
// Wait
}
...
}
interrupt void InterruptB()
{
flag = true ;
}
... переменная flag должна быть энергозависимой, чтобы гарантировать, что чтение в ThreadA не оптимизировано, однако, если флаг был прочитан через функцию, таким образом...
volatile bool flag = false ;
bool ReadFlag() { return flag }
void ThreadA()
{
...
while ( !ReadFlag() )
{
// Wait
}
...
}
... еще flag все еще нуждается в изменчивости? Я понимаю, что нет никакого вреда в том, что он нестабилен, но я беспокоюсь о том, когда он опускается, а упущение не замечено; будет ли это безопасно?
Приведенный выше пример тривиален; в реальном случае (и причина моего запроса) у меня есть библиотека классов, которая обертывает RTOS, так что существует абстрактный класс cTask, из которого происходят объекты задачи. Такие "активные" объекты обычно имеют функции-члены, которые обращаются к данным, которые могут быть изменены в контексте объектной задачи, но доступны из других контекстов; критически ли тогда такие данные объявляются изменчивыми?
Мне действительно интересно то, что гарантировано в отношении таких данных, а не то, что может сделать практический компилятор. Я могу протестировать несколько компиляторов и найти, что они никогда не оптимизируют чтение через аксессуар, но затем однажды найдут компилятор или настройку компилятора, что делает это предположение неверным. Я мог представить себе, например, что если функция была встроена, такая оптимизация была бы тривиальной для компилятора, потому что она не отличалась бы от прямого чтения.
