атомарное чтение и запись gcc

Определите «безопасно».

Если вы просто используете обычное чтение на x86 для естественно выровненных 32-битных или меньших данных, чтение будет атомарным, поэтому вы всегда будете читать действительное значение, а не то, которое содержит некоторые байты, записанные одним потоком, а некоторые - другим. Если что-то из этого не соответствует действительности (не x86, не выровнено естественным образом, больше 32 бит ...), все ставки отключены.

Тем не менее, у вас нет никакой гарантии, что прочитанное значение будет особенно свежим или что последовательность значений, наблюдаемых при нескольких чтениях, будет в каком-либо определенном порядке. Я видел наивный код, использующий volatile, чтобы победить компилятор, полностью оптимизирующий чтение, но никакой другой механизм синхронизации буквально никогда не видел обновленное значение из-за кэширования ЦП.

Если что-то из этого имеет для вас значение, а они действительно должны иметь значение, вы должны явно сделать чтение атомарным и использовать соответствующие барьеры памяти. Внутренние функции, на которые вы ссылаетесь, позаботятся обо всех этих вещах за вас: вы можете вызвать одну из атомарных встроенных функций таким образом, чтобы не было побочных эффектов, кроме возврата значения:

__sync_val_compare_and_swap(ptr, 0, 0)

or

__sync_add_and_fetch(ptr, 0)

or

__sync_sub_and_fetch(ptr, 0)

или что-то еще

Если ваш компилятор поддерживает это, вы можете использовать атомарные типы C11. Они представлены в разделе 7.17 стандарта, но, к сожалению, являются необязательными, поэтому вам нужно будет проверить, определено ли __STDC_NO_ATOMICS__, чтобы, по крайней мере, выдать значимую ошибку, если она не поддерживается.

С gcc вам, по-видимому, нужна как минимум версия 4.9, потому что в противном случае заголовок отсутствует (вот такой вопрос по этому поводу, но я могу '' не проверять, потому что у меня нет GCC-4.9).

Я отвечу на ваш вопрос, но вы должны знать заранее, что атомная энергия не из дешевых. ЦП должен синхронизировать между ядрами каждый раз, когда вы используете атомики, и вам не понравятся результаты производительности, если вы используете атомики в жестком цикле.

На странице, на которую вы ссылаетесь, перечислены атомарные операции для writer, но ничего не говорится о том, как следует читать такие переменные. Ответ заключается в том, что другие ядра вашего ЦП будут «видеть» обновленные значения, но ваш компилятор может «кэшировать» старое значение в регистре или в стеке. Чтобы предотвратить такое поведение, я предлагаю вам объявить переменную volatile, чтобы ваш компилятор не кэшировал старое значение.

Единственная проблема безопасности, с которой вы столкнетесь, - это устаревшие данные, как описано выше.

Если вы попытаетесь сделать что-нибудь более сложное с помощью атомики, вы можете столкнуться с тонкими и случайными проблемами с порядком, в котором атомики записываются одним потоком, по сравнению с порядком, в котором вы видите эти изменения в другом потоке. К сожалению, вы не используете встроенную функцию языка, а встроенные функции компилятора разработаны не идеально. Если вы решите использовать эти встроенные функции, я предлагаю вам максимально упростить свою логику.

Если бы я понял проблему, я бы не использовал атомарные переменные для счетчиков. У каждого рабочего потока может быть отдельный счетчик, который он обновляет локально, главный поток может читать весь массив счетчиков для приблизительного значения моментального снимка, так что это становится проблемой 1 потребитель 1 производитель. Память может быть сделана видимой для главного потока, например, каждые 5 секунд с помощью __sync_synchronize () или аналогичного.