Может ли num++ быть атомарным для 'int num'?

...а теперь давайте включим оптимизацию:

f():
        rep ret

хорошо, давайте дадим ему шанс:

void f(int& num)
{
  num = 0;
  num++;
  --num;
  num += 6;
  num -=5;
  --num;
}

результат:

f(int&):
        mov     DWORD PTR [rdi], 0
        ret

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

сравнить с:

#include <atomic>

void f(std::atomic<int>& num)
{
  num = 0;
  num++;
  --num;
  num += 6;
  num -=5;
  --num;
}

где результат:

f(std::atomic<int>&):
        mov     DWORD PTR [rdi], 0
        mfence
        lock add        DWORD PTR [rdi], 1
        lock sub        DWORD PTR [rdi], 1
        lock add        DWORD PTR [rdi], 6
        lock sub        DWORD PTR [rdi], 5
        lock sub        DWORD PTR [rdi], 1
        ret

теперь каждая модификация: -

1. наблюдаемый в другом потоке, и
2. уважительно относится к подобным модификациям, происходящим в других потоках.

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

дополнительная информация

относительно эффекта оптимизации обновлений std::atomic s.

стандарт c++ имеет правило "как бы", по которому компилятору разрешается переупорядочивать код, и даже перепишите код при условии, что результат имеет точно такой же наблюдаемый эффекты (включая побочные эффекты), как если бы он просто выполнил ваш код.

правило as-if является консервативным, особенно с участием атомной энергетики.

считаем:

void incdec(int& num) {
    ++num;
    --num;
}

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

void incdec(int&) {
    // nada
}

это связано с тем, что в модели памяти c++ нет возможности другого потока, наблюдающего результат приращения. Было бы, конечно, по-другому, если num был volatile (может повлиять на поведение оборудования). Но в этом случае эта функция будет единственной функцией, модифицирующей эту память (в противном случае программа плохо сформирована).

однако, это другая игра в мяч:

void incdec(std::atomic<int>& num) {
    ++num;
    --num;
}

num является атомарным. Изменения в нем должны быть заметным для других потоков, которые наблюдают. Изменения, которые сами эти потоки делают (например, установка значения 100 между приращением и уменьшением), будут иметь очень далеко идущие последствия для конечного значения num.

вот демо:

#include <thread>
#include <atomic>

int main()
{
    for (int iter = 0 ; iter < 20 ; ++iter)
    {
        std::atomic<int> num = { 0 };
        std::thread t1([&] {
            for (int i = 0 ; i < 10000000 ; ++i)
            {
                ++num;
                --num;
            }
        });
        std::thread t2([&] {
            for (int i = 0 ; i < 10000000 ; ++i)
            {
                num = 100;
            }
        });

        t2.join();
        t1.join();
        std::cout << num << std::endl;
    }
}

пример вывода:

99
99
99
99
99
100
99
99
100
100
100
100
99
99
100
99
99
100
100
99

без многих осложнений инструкция как add DWORD PTR [rbp-4], 1 очень CISC-стиль.

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

AGENT 1          AGENT 2

load X              
inc C
                 load X
                 inc C
                 store X
store X

X увеличивается только один раз.

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

IIRC атомарный вариант инструкции add называется xadd замок

поскольку строка 5, которая соответствует num++, является одной инструкцией, можем ли мы заключить, что num++ является атомарным в этом случае?

опасно делать выводы на основе" обратного инжиниринга " генерируемой сборки. Например, вы, похоже, скомпилировали свой код с отключенной оптимизацией, иначе компилятор выбросил бы эту переменную или загрузил 1 непосредственно в нее без вызова operator++. Потому что сгенерированная сборка может значительно измениться, на основе флагов оптимизации, целевого процессора и т. д. ваш вывод основан на песке.

кроме того, ваша идея о том, что одна инструкция по сборке означает, что операция является атомной, также неверна. Это add не будет атомарным на многопроцессорных системах, даже на архитектуре x86.

даже если ваш компилятор всегда выдавал это как атомарную операцию, доступ к num из любого другого потока одновременно будет составлять гонку данных в соответствии со стандартами C++11 и C++14, и программа будет иметь неопределенное поведение.

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

int main()
{
  std::unique_ptr<std::vector<int>> vec;
  int ready = 0;
  std::thread t{[&]
    {
       while (!ready);
       // use "vec" here
    });
  vec.reset(new std::vector<int>());
  ++ready;
  t.join();
}

даже если предположить оптимистично, что ++ready является "атомарным", и что компилятор генерирует цикл проверки по мере необходимости (как я уже сказал, это UB, и поэтому компилятор может удалить его, заменить его бесконечным циклом и т. д.), компилятор может по-прежнему перемещать назначение указателя, или даже хуже инициализации vector до точки, после операции увеличения, вызывая хаос в новом нитка. На практике я бы не удивился, если бы оптимизирующий компилятор удалил ready переменная и цикл проверки полностью, так как это не влияет на наблюдаемое поведение в соответствии с правилами языка (в отличие от ваших частных надежд).

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

наконец, даже если вы не заботились о переносимости, и ваш компилятор был волшебно хорош, процессор, который вы используете, очень вероятно, имеет суперскалярный тип CISC и будет разбивать инструкции на микро-ops, переупорядочивать и / или спекулятивно выполнять их, в степени, ограниченной только синхронизацией примитивов, таких как (на Intel)LOCK префикс или заборы памяти, в порядке для максимизации операций в секунду.

короче говоря, естественными обязанностями потокобезопасного программирования являются:

1. ваша обязанность-написать код, который имеет четко определенное поведение в соответствии с языковыми правилами (и, в частности, модель стандартной памяти языка).
2. ваш компилятор обязан генерировать машинный код, который имеет такое же четко определенное (наблюдаемое) поведение в модели памяти целевой архитектуры.
3. ваш ЦП обязан выполнить этот код так, чтобы наблюдаемое поведение было совместимо с моделью памяти его собственной архитектуры.

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

PS: правильно написанный пример:

int main()
{
  std::unique_ptr<std::vector<int>> vec;
  std::atomic<int> ready{0}; // NOTE the use of the std::atomic template
  std::thread t{[&]
    {
       while (!ready);
       // use "vec" here
    });
  vec.reset(new std::vector<int>());
  ++ready;
  t.join();
}

это безопасно, так:

1. проверки ready не может быть оптимизирован в соответствии с языковыми правилами.
2. The ++readyпроисходит-перед чек, который видит ready не ноль, и другие операции не могут быть переупорядочены вокруг этих операций. Это потому что ++ready и чек последовательно последовательное, который является еще одним термином, описанным в модели памяти C++, и который запрещает это конкретное переупорядочение. Поэтому компилятор не должен переупорядочивать инструкции, а также должен сообщать процессору что он не должен, например, откладывать запись в vec после приращения ready. последовательно последовательное самая сильная гарантия относительно Атомик в стандарте языка. Меньшие (и теоретически более дешевые) гарантии доступны, например, с помощью других методов std::atomic<T>, но они определенно предназначены только для экспертов и не могут быть оптимизированы разработчиками компиляторов, потому что они редко используются.

на одноядерной машине x86,add инструкция обычно будет атомарной по отношению к другому коду на CPU¹. Прерывание не может разделить одну инструкцию посередине.

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

современный x86 системы Multi-сердечника, поэтому однопроцессорный особый случай не распространяется.

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

(это не поможет вам, если вы пишете на C++, хотя. Компиляторы не имеют возможности требовать num++ для компиляции в a memory-destination add or xadd без a lock префикс. Они могли бы выбрать, чтобы загрузить num в регистр и хранить результат приращения с отдельной инструкцией, и, вероятно, сделать это, если вы используете результат.)

---

Сноска 1:lock префикс существовал даже на оригинальном 8086, потому что устройства ввода / вывода работают одновременно с процессором; драйверы на одноядерной системе нужны lock add атомарно увеличить значение в памяти устройства, если устройство также может измените его, или в отношении доступа DMA.

еще в тот день, когда компьютеры x86 имели один процессор, использование одной инструкции гарантировало, что прерывания не будут разделять чтение/изменение/запись, и если память не будет использоваться в качестве буфера DMA, она была атомарной на самом деле (и C++ не упоминал потоки в стандарте, поэтому это не были адреса).

когда было редко иметь двухъядерный (Pentium Pro) на рабочем столе клиента, я эффективно использовал это, чтобы избежать префикса блокировки на одноядерной машине и повысить производительность.

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

с современными процессорами x86 / x64, одна инструкция разбивается на несколько micro ops и, кроме того, чтение и запись памяти буферизуется. Так что разные потоки работают различные процессоры не только увидят это как неатомное, но и могут увидеть противоречивые результаты относительно того, что он читает из памяти и что он предполагает, что другие потоки прочитали до этого момента времени: вам нужно добавить защита памяти для восстановления нормального поведения.

нет. https://www.youtube.com/watch?v=31g0YE61PLQ (Это просто ссылка на сцену" нет " из "офиса")

согласны ли вы, что это было бы возможным выходом для программы:

пример вывода:

100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100

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

это правило" как-будто".

и независимо от вывода, вы можете думать о синхронизации потоков одинаково - если поток A делает num++; num--; и поток B читает num неоднократно, то возможным допустимым чередованием является то, что поток B никогда не читает между num++ и num--. Поскольку это чередование допустимо, компилятор может сделать это только возможно чередование. И просто удалите incr / decr полностью.

есть некоторые интересные последствия здесь:

while (working())
    progress++;  // atomic, global

(т. е. Представьте, что какой-то другой поток обновляет интерфейс индикатора выполнения на основе progress)

может ли компилятор превратить это в:

int local = 0;
while (working())
    local++;

progress += local;

вероятно, это действительно так. Но, вероятно, не то, на что надеялся программист: - (

комитет все еще работает над этим материалом. В настоящее время он "работает", потому что компиляторы не оптимизируют Атомикс. Но это меняется.

и даже если progress было также изменчиво, это было бы по-прежнему действительны:

int local = 0;
while (working())
    local++;

while (local--)
    progress++;

: -/

да, но...

Atomic-это не то, что вы хотели сказать. Ты, наверное, спрашиваешь не то.

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

Это потокобезопасным?

это другой вопрос, и есть по крайней мере две веские причины, чтобы ответить с определенным "нет!".

во-первых, существует вероятность того, что у другого ядра может быть копия этой строки кэша в L1 (L2 и выше обычно разделяются, но L1 обычно на ядро!), и одновременно изменяет это значение. Конечно, это происходит и атомарно, но теперь у вас есть два "правильных" (правильно, атомарно, модифицированных) значения-какое из них действительно правильное сейчас?
Процессор, конечно, как-то разберется. Но результат может быть не таким, как вы ожидаете.

во-вторых, есть упорядочение памяти, или адрес по-другому происходит-перед гарантиями. Самое главное в атомарных инструкциях не столько то, что они atomic. Это заказ.

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

например, вы можете установить указатель на блок данных (например, результаты некоторых вычислений), а затем атомарно релиз флаг "данные готовы". Теперь, кто бы ни был приобретает этот флаг приведет к мысли, что указатель действителен. И действительно, это будет всегда быть действительным указателем, никогда ничего другого. Это потому, что запись в указатель произошла-до атомной операции.

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

обратите внимание, что атомика (с помощью lock префикс инструкции) относительно тяжелы на x86 (посмотреть этот ответ), но все же заметно меньше, чем мьютекс, что не очень уместно в этом случае использования.

следующие результаты взяты из Clang++ 3.8 при компиляции с -Os.

увеличение int по ссылке, "обычный" способ:

void inc(int& x)
{
    ++x;
}

это компилируется в :

inc(int&):
    incl    (%rdi)
    retq

увеличение int, передаваемого по ссылке, атомарный путь:

#include <atomic>

void inc(std::atomic<int>& x)
{
    ++x;
}

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

inc(std::atomic<int>&):
    lock            incl    (%rdi)
    retq

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

попробуйте скомпилировать тот же код на машине без x86, и вы быстро увидите очень разные результаты сборки.

причина num++появляется быть атомарным-это потому, что на машинах x86 увеличение 32-разрядного целого числа фактически является атомарным (при условии, что извлечение памяти не происходит). Но это не гарантируется стандартом c++, и это вряд ли будет иметь место на машине, которая не использует набор инструкций x86. Таким образом, этот код не является кросс-платформенным безопасным состязание.

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

причина, значит, в том, что у нас std::atomic<int> и так далее, так что, когда вы работаете с архитектурой, где атомарность базовых вычислений не гарантируется, у вас есть механизм, который заставит компилятор генерировать атомарный код.