g_atomic_int_get гарантирует видимость в другой поток?

Question

Это связано с этим вопросом .

Заявление rmmh по этому вопросу состояло в том, что на определенных архитектурах не требуется никакой особой магии для реализации атомарного получения и установки.В частности, в этом случае g_atomic_int_get (& foo) из glib просто расширяется до (* (& foo)).Я понимаю, что это означает, что foo не будет находиться во внутренне согласованном состоянии.Однако я также гарантирую, что foo не будет кэшироваться данным процессором или ядром?

В частности, если один поток устанавливает foo, а другой читает его (используя функции glib g_atomic_ *), могу ли я предположитьчто читатель увидит обновления переменной, сделанные автором.Или писатель может просто обновить значение в регистре?Для справки моей целевой платформой является gcc (4.1.2) на многоядерном многопроцессорном компьютере X86_64.

Answer 1

То, что обеспечивает (включает) большинство архитектур, - это атомарность и согласованность операций чтения и записи с соответствующим размером и выравниванием чтения / записи (поэтому каждый процессор видит подпоследовательность одной и той же главной последовательности значений для данного адреса памяти (*)),и int, скорее всего, имеет подходящий размер, и компиляторы обычно гарантируют, что они также правильно выровнены.

Но компиляторы редко гарантируют, что они не оптимизируют некоторые операции чтения или записи, если они не помечены каким-либо образом.или другой.Я попытался скомпилировать:

int f(int* ptr)
{
    int i, r=0;
    *ptr = 5;
    for (i = 0; i < 100; ++i) {
        r += i*i;
    }
    *ptr = r;
    return *ptr;
}

с gcc 4.1.2. Gcc без проблем оптимизировал первую запись в *ptr, что вам, вероятно, не нужно для атомарной записи.

(*) Согласованность не следует путать с согласованностью: взаимосвязь между чтением и записью по разному адресу часто ослаблена в отношении интуитивной, но дорогостоящей в реализации последовательной согласованности.Вот почему необходимы барьеры памяти.

Answer 2

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

В зависимости от архитектуры некоторые инструкции являются атомарными. запись в целое число и чтение из целого числа часто являются атомарными. Если gcc использует атомарные инструкции для чтения / записи в целочисленную область памяти, один поток не будет считывать «промежуточный мусор», если другой поток находится в середине записи.

Но вы можете столкнуться с проблемами из-за переупорядочения компилятора и перестановки команд.

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

__asm__ __volatile__ ("" ::: "memory");

Даже если компилятор не переупорядочивает код, ЦП постоянно переупорядочивает инструкции во время выполнения. Вот очень хорошая статья на эту тему. «Барьер памяти» используется для предотвращения изменения порядка команд процессором через барьер. Вот один из возможных способов сделать барьер памяти с помощью gcc:

__sync_synchronize();

Вы также можете выполнять инструкции asm для создания различных барьеров.

Тем не менее, мы читаем и пишем глобальные целые числа без использования атомарных операций или мьютексов из нескольких потоков и не имеем проблем. Скорее всего, это связано с тем, что: A) мы работаем на Intel, а Intel не переупорядочивает инструкции агрессивно, и B) выполняется достаточно кода, прежде чем мы сделаем что-то «плохое» с ранним чтением флага. В нашу пользу также тот факт, что многие системные вызовы имеют барьеры, а атомарные операции gcc являются барьерами. Мы используем много атомарных операций.

Вот хорошее обсуждение переполнения стека аналогичного вопроса.