Обновление : Этот ответ неверен, так как мне не хватает того факта, что volatile
гарантирует, что доступ к volatile
переменным не переупорядочен, но не предоставляет таких гарантий в отношении других volatile
доступы и манипуляции. Забор памяти предоставляет такие гарантии и необходим для этого применения. Мой оригинальный ответ ниже, но не действуйте на него. См. этот ответ для хорошего объяснения в дыре в моем понимании, которая привела к следующему неправильному ответу.
Оригинальный ответ:
Да, вам нужно volatile
в вашей декларации rt_data
; каждый раз, когда переменная может быть изменена вне потока управления потока, обращающегося к ней, она должна быть объявлена volatile
. Хотя вы можете обойтись без volatile
, так как вы копируете в локальный указатель, volatile
, по крайней мере, помогает с документацией, а также запрещает некоторые оптимизации компилятора, которые могут вызвать проблемы. Рассмотрим следующий пример, принятый из DDJ :
volatile int a;
int b;
a = 1;
b = a;
Если для a
возможно изменить его значение между a=1
и b=a
, тогда a
должно быть объявлено volatile
(если, конечно, не присвоено устаревшее значение b
приемлемо). Многопоточность, особенно с атомарными примитивами, представляет собой такую ситуацию. Ситуация также инициируется переменными, измененными обработчиками сигналов и переменными, отображаемыми в нечетные ячейки памяти (например, аппаратные регистры ввода / вывода). Смотри также этот вопрос .
В остальном это выглядит нормально для меня.
В C я бы, вероятно, использовал для этого атомарные примитивы, предоставляемые GLib . Они будут использовать атомарную операцию там, где она доступна, и прибегнут к медленной, но правильной реализации на основе мьютекса, если атомарные операции недоступны. Boost может обеспечить нечто подобное для C ++.