Может ли 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::atomics.

стандарт 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-стиль.

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

AGENT 1          AGENT 2

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

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

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

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 и будет разбивать инструкции на микрооперации, переупорядочивать и / или спекулятивно выполнять их, в степени, ограниченной синхронизацией примитивов, таких как (на Intel)LOCK префикс или память заборы, в порядке максимизировать операции в секунду.

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

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

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

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

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

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

современный x86 системы являются многоядерными, поэтому особый случай uniprocessor не применяется.

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

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

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

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

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

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

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

нет. 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

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

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

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

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

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

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

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

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

progress += local;

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

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

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

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

while (local--)
    progress++;

: -/

да, но...

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

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

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

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

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

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

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

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

что выход одного компилятора на определенной архитектуре процессора с отключенными оптимизациями (поскольку gcc даже не компилирует ++ до add при оптимизации в быстром и грязном примере), похоже, подразумевает, что приращение таким образом является атомарным, не означает, что это соответствует стандарту (вы вызовете неопределенное поведение при попытке доступа num в потоке), и все равно неправильно, потому что add is не atomic в 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> и так далее, так что, когда вы работаете с архитектурой, где атомарность базовых вычислений не гарантируется, у вас есть механизм, который заставит компилятор генерировать атомарный код.