std::atomic
існує тому, що багато ISA мають пряму апаратну підтримку для нього
Що говорить стандарт C ++ std::atomic
, було проаналізовано в інших відповідях.
Тож тепер давайте подивимося, що std::atomic
компілюється, щоб отримати інший вид розуміння.
Основним висновком цього експерименту є те, що сучасні процесори мають пряму підтримку атомних цілочисельних операцій, наприклад, префікса LOCK у x86, і в std::atomic
основному існує як портативний інтерфейс для цих втручань: Що означає інструкція "замок" у складі x86? В архіві64 буде використано LDADD .
Ця підтримка дозволяє отримати більш швидкі альтернативи більш загальним методам, таким як std::mutex
, який може зробити складніші секції з декількома інструкціями атомними, за рахунок того, що вони будуть повільнішими, ніж std::atomic
через std::mutex
те, що він робить futex
системні дзвінки в Linux, але це набагато повільніше, ніж інструкції з користувальницьких даних std::atomic
, див. також: Чи створює std :: mutex паркан?
Розглянемо наступну багатопотокову програму, яка збільшує глобальну змінну по декількох потоках, з різними механізмами синхронізації залежно від того, який визначення препроцесора використовується.
main.cpp
#include <atomic>
#include <iostream>
#include <thread>
#include <vector>
size_t niters;
#if STD_ATOMIC
std::atomic_ulong global(0);
#else
uint64_t global = 0;
#endif
void threadMain() {
for (size_t i = 0; i < niters; ++i) {
#if LOCK
__asm__ __volatile__ (
"lock incq %0;"
: "+m" (global),
"+g" (i) // to prevent loop unrolling
:
:
);
#else
__asm__ __volatile__ (
""
: "+g" (i) // to prevent he loop from being optimized to a single add
: "g" (global)
:
);
global++;
#endif
}
}
int main(int argc, char **argv) {
size_t nthreads;
if (argc > 1) {
nthreads = std::stoull(argv[1], NULL, 0);
} else {
nthreads = 2;
}
if (argc > 2) {
niters = std::stoull(argv[2], NULL, 0);
} else {
niters = 10;
}
std::vector<std::thread> threads(nthreads);
for (size_t i = 0; i < nthreads; ++i)
threads[i] = std::thread(threadMain);
for (size_t i = 0; i < nthreads; ++i)
threads[i].join();
uint64_t expect = nthreads * niters;
std::cout << "expect " << expect << std::endl;
std::cout << "global " << global << std::endl;
}
GitHub вище за течією .
Складіть, запустіть і розберіть:
comon="-ggdb3 -O3 -std=c++11 -Wall -Wextra -pedantic main.cpp -pthread"
g++ -o main_fail.out $common
g++ -o main_std_atomic.out -DSTD_ATOMIC $common
g++ -o main_lock.out -DLOCK $common
./main_fail.out 4 100000
./main_std_atomic.out 4 100000
./main_lock.out 4 100000
gdb -batch -ex "disassemble threadMain" main_fail.out
gdb -batch -ex "disassemble threadMain" main_std_atomic.out
gdb -batch -ex "disassemble threadMain" main_lock.out
Надзвичайно вірогідний "неправильний" результат перегонів для main_fail.out
:
expect 400000
global 100000
і детермінований "правильний" вихід інших:
expect 400000
global 400000
Розбирання main_fail.out
:
0x0000000000002780 <+0>: endbr64
0x0000000000002784 <+4>: mov 0x29b5(%rip),%rcx # 0x5140 <niters>
0x000000000000278b <+11>: test %rcx,%rcx
0x000000000000278e <+14>: je 0x27b4 <threadMain()+52>
0x0000000000002790 <+16>: mov 0x29a1(%rip),%rdx # 0x5138 <global>
0x0000000000002797 <+23>: xor %eax,%eax
0x0000000000002799 <+25>: nopl 0x0(%rax)
0x00000000000027a0 <+32>: add $0x1,%rax
0x00000000000027a4 <+36>: add $0x1,%rdx
0x00000000000027a8 <+40>: cmp %rcx,%rax
0x00000000000027ab <+43>: jb 0x27a0 <threadMain()+32>
0x00000000000027ad <+45>: mov %rdx,0x2984(%rip) # 0x5138 <global>
0x00000000000027b4 <+52>: retq
Розбирання main_std_atomic.out
:
0x0000000000002780 <+0>: endbr64
0x0000000000002784 <+4>: cmpq $0x0,0x29b4(%rip) # 0x5140 <niters>
0x000000000000278c <+12>: je 0x27a6 <threadMain()+38>
0x000000000000278e <+14>: xor %eax,%eax
0x0000000000002790 <+16>: lock addq $0x1,0x299f(%rip) # 0x5138 <global>
0x0000000000002799 <+25>: add $0x1,%rax
0x000000000000279d <+29>: cmp %rax,0x299c(%rip) # 0x5140 <niters>
0x00000000000027a4 <+36>: ja 0x2790 <threadMain()+16>
0x00000000000027a6 <+38>: retq
Розбирання main_lock.out
:
Dump of assembler code for function threadMain():
0x0000000000002780 <+0>: endbr64
0x0000000000002784 <+4>: cmpq $0x0,0x29b4(%rip) # 0x5140 <niters>
0x000000000000278c <+12>: je 0x27a5 <threadMain()+37>
0x000000000000278e <+14>: xor %eax,%eax
0x0000000000002790 <+16>: lock incq 0x29a0(%rip) # 0x5138 <global>
0x0000000000002798 <+24>: add $0x1,%rax
0x000000000000279c <+28>: cmp %rax,0x299d(%rip) # 0x5140 <niters>
0x00000000000027a3 <+35>: ja 0x2790 <threadMain()+16>
0x00000000000027a5 <+37>: retq
Висновки:
безотомна версія зберігає глобальний реєстр і збільшує регістр.
Тому, зрештою, дуже ймовірно, що чотири записи повертаються до глобальних з однаковим "неправильним" значенням 100000
.
std::atomic
компілює до lock addq
. Префікс LOCK робить наступне inc
отримання, зміни та оновлення пам'яті атомним шляхом.
наш явний вбудований префікс LOCK компілюється майже до того ж std::atomic
, що інакше, за винятком того, що наш inc
використовується замість add
. Не впевнений, чому GCC обрав add
, враховуючи, що наш INC генерував декодування на 1 байт менше.
ARMv8 може використовувати або LDAXR + STLXR, або LDADD в нових процесорах: Як запустити теми в звичайному C?
Тестовано в Ubuntu 19.10 AMD64, GCC 9.2.1, Lenovo ThinkPad P51.
a.fetch_add(12)
якщо ви хочете атомну RMW.