ПВТ - весна 2015 - Лекция 7. Модель памяти С++. Внеочередное выполнение инструкций. Барьеры памяти. Атомарные операции
1 like935 views
Лекция охватывает атомарные операции, их важность в многопоточном программировании, и как они предотвращают гонки данных. Рассматриваются особенности работы атомарных видов данных в C++ и их использование для обеспечения корректности выполнения многопоточных приложений. Описываются также различные операции, такие как сравнение и обмен, а также механизмы оптимизации на уровне компилятора.
![Фрагментированные чтения и записи
strd r0, r1, [r2]
▪ Инструкции могут быть неатомарными, даже если
выполняются одной процессорной инструкцией.
Например, в ARMv7 инструкция для помещения содержимого
двух 32-битных регистров в один 64-битный:
На некоторых процессорах эта инструкция реализуются двумя
отдельными операциями сохранения.
32-битная операция mov атомарна только для выравненных
данных. В остальных случаях операция неатомарная
▪ Вытеснение потоков, выполняющих данные операции, или
выполнение операций в двугих потоках в многоядерных
системах приводит к неопределённому поведению.
9](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-9-320.jpg)
![Атомарный тип atomic<T*>
Функции для типа atomic<T*>:
▪ is_lock_free, load, store, exchange,
compare_exchange_weak, compare_exchange_strong
▪ обменять и прибавить:
fetch_add, operator++, operator+=
▪ обменять и вычесть:
fetch_sub, operator--, operator-=
class C {};
C arr[10];
std::atomic<C*> ptr(arr);
C* x = ptr.fetch_add(2);
assert(x == arr);
assert(p.load() == &some_array[2]);
p--; x = p;
assert(x == &arr[1]);
операции
чтения-
модификации-
записи
21](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-21-320.jpg)
![Компиляторная оптимизация - примеры оптимизаций
x = 1;
y = 2;
x = 3;
for (i = 0; i < n; i++)
sum += a[i];
y = 2;
x = 3;
r1 = sum;
for (i = 0; i < n; i++)
r1 += a[i];
sum = r1;
for (i = 0; i < n; i++)
j = 42 * i;
j = -42
for (i = 0; i < n; i++)
j = j + 42;
36](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-36-320.jpg)
![Компиляторная оптимизация - примеры оптимизаций
x = Johann;
y = Sebastian;
z = Bach;
for (i = 0; i < n; i++)
for (j = 0; j < m;j++);
a[i][j] = 1;
z = Bach;
x = Johann;
y = Sebastian;
for (j = 0; j < n; j++)
for (i = 0; i < m;
i++);
a[i][j] = 1;
for (i = 0; i < n; i++)
a[i] = 1;
for (i = 0; i < n; i++)
b[i] = 2;
for (i = 0; i < n; i++)
{
a[i] = 1;
b[i] = 2;
} 37](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-37-320.jpg)
![Переупорядочивание в процессорах архитектуры x86
Поток 1
x = 1;
asm volatile("mfence" :::
"memory");
asm volatile("" :::
"memory");
r1 = y;
Программный барьер памяти:
запретить переупорядочивание
инструкций компилятором.
Аппаратный барьер памяти:
запретить переупорядочивание
инструкций процессором.
67
mov DWORD PTR X[rip], 1
mfence
mov eax, DWORD PTR Y[rip]
...
mov DWORD PTR r1[rip], eax
полный барьер памяти](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-67-320.jpg)
![Переупорядочивание при выполнении операция захвата-освобождения в
процессорах архитектуры POWER
Поток 1 (процессор 1)
// Подготавливаем данные
// и устанавливаем флаг
// готовности
for (i = 0; i < n; i++) {
widget[i].x = x;
widget[i].y = y;
widget[i].ready = true;
}
Поток 2 (процессор 2)
// Если данные готовы,
// обрабатываем их
for (i = 0; i < n; i++) {
if (widget[i].ready) {
do_some_stuff(widget[i]);
}
}
L2-кэш
Буфер 1 Буфер 2 Буфер N
... ...
77](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-77-320.jpg)
![Переупорядочивание при выполнении операция захвата-освобождения в
процессорах архитектуры POWER
Поток 1 (процессор 1)
// Подготавливаем данные
// и устанавливаем флаг
// готовности
for (i = 0; i < n; i++) {
widget[i].x = x;
widget[i].y = y;
widget[i].ready = true;
}
Поток 2 (процессор 2)
// Если данные готовы,
// обрабатываем их
for (i = 0; i < n; i++) {
if (widget[i].ready) {
do_some_stuff(widget[i]);
}
}
L2-кэш
Буфер 1 Буфер 2 Буфер N
... ...
78](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-78-320.jpg)
![Переупорядочивание при выполнении операция захвата-освобождения в
процессорах архитектуры POWER
Поток 1 (процессор 1)
// Подготавливаем данные
// и устанавливаем флаг
// готовности
for (i = 0; i < n; i++) {
widget[i].x = x;
widget[i].y = y;
widget[i].ready = true;
}
Поток 2 (процессор 2)
// Если данные готовы,
// обрабатываем их
for (i = 0; i < n; i++) {
if (widget[i].ready) {
do_some_stuff(widget[i]);
}
}
L2-кэш
Буфер 1 Буфер 2 Буфер N
... ...
79](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-79-320.jpg)
![Переупорядочивание при выполнении операция захвата-освобождения в
процессорах архитектуры POWER
Поток 1 (процессор 1)
// Подготавливаем данные
// и устанавливаем флаг
// готовности
for (i = 0; i < n; i++) {
widget[i].x = x;
widget[i].y = y;
widget[i].ready = true;
}
Поток 2 (процессор 2)
// Если данные готовы,
// обрабатываем их
for (i = 0; i < n; i++) {
if (widget[i].ready) {
do_some_stuff(widget[i]);
}
}
L2-кэш
Буфер 1 Буфер 2 Буфер N
... ...
80](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-80-320.jpg)
![Переупорядочивание при выполнении операция захвата-освобождения в
процессорах архитектуры POWER
Поток 1 (процессор 1)
// Подготавливаем данные
// и устанавливаем флаг
// готовности
for (i = 0; i < n; i++) {
widget[i].x = x;
widget[i].y = y;
widget[i].ready = true;
}
Поток 2 (процессор 2)
// Если данные готовы,
// обрабатываем их
for (i = 0; i < n; i++) {
if (widget[i].ready) {
do_some_stuff(widget[i]);
}
}
L2-кэш: widget[i].y = y; widget[i].ready = true;
... ...
81](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-81-320.jpg)
![Переупорядочивание при выполнении операция захвата-освобождения в
процессорах архитектуры POWER
Поток 1 (процессор 1)
// Подготавливаем данные
// и устанавливаем флаг
// готовности
for (i = 0; i < n; i++) {
widget[i].x = x;
widget[i].y = y;
widget[i].ready = true;
}
Поток 2 (процессор 2)
// Если данные готовы,
// обрабатываем их
for (i = 0; i < n; i++) {
if (widget[i].ready) {
do_some_stuff(widget[i]);
}
}
L2-кэш: widget[i].y = y; widget[i].ready = true;
... ...
StoreStore
82](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-82-320.jpg)
![Программное переупорядочивание инструкций
mov eax, DWORD PTR y[rip]
add eax, 111
mov DWORD PTR x[rip], eax
mov DWORD PTR y[rip], 222
int x, y;
int main() {
x = y + 111;
y = 222;
printf("%d%d", x, y);
gcc -S -masm=intel prog.c
выполнение команды
x = y + 111 завершено
выполнение команды
y = 222 завершено
85](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-85-320.jpg)
![Программное переупорядочивание инструкций
mov eax, DWORD PTR y[rip]
mov edx, 222
...
mov DWORD PTR y[rip], 222
lea esi, [rax+111]
...
mov DWORD PTR x[rip], esi
int x, y;
int main() {
x = y + 111;
y = 222;
printf("%d%d", x, y);
gcc -S -masm=intel -O2 prog.c
выполнение команды
y = 222 завершено
выполнение команды
x = y + 111 завершено
y = 222 выполняется
раньше x = y + 111
86](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-86-320.jpg)
![Программное переупорядочивание инструкций
mov eax, DWORD PTR y[rip]
add eax, 111
mov DWORD PTR x[rip], eax
mov esi, DWORD PTR x[rip]
mov edx, 222
...
xor eax, eax
mov DWORD PTR y[rip], 222
int x, y;
int main() {
x = y + 111;
asm volatile("" ::: "memory");
y = 222;
printf("%d%d", x, y);
gcc -S -masm=intel -O2 prog.c
явный барьер
87](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-87-320.jpg)
![Происходит-раньше не означает происходит раньше
mov eax, DWORD PTR y[rip]
mov edx, 222
...
mov DWORD PTR y[rip], 222
lea esi, [rax+111]
...
mov DWORD PTR x[rip], esi
int x, y;
int main() {
x = y + 111; // A
y = 222; // B
printf("%d%d", x, y);
gcc -S -masm=intel -O2 prog.c
1. Из того, что А происходит-раньше В не следует, что А
происходит раньше В.
108](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-108-320.jpg)
![Происходит-раньше не означает происходит раньше
mov eax, DWORD PTR y[rip]
mov edx, 222
...
mov DWORD PTR y[rip], 222
lea esi, [rax+111]
...
mov DWORD PTR x[rip], esi
int x, y;
int main() {
x = y + 111;
y = 222;
printf("%d%d", x, y);
gcc -S -masm=intel -O2 prog.c
выполнение команды
y = 222 завершено
выполнение команды
x = y + 111 завершено
y = 222 выполняется
раньше x = y + 111
1. Из того, что А происходит-раньше В не следует, что А
происходит раньше В.
109](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-109-320.jpg)
![Последовательная согласованность (sequential consistency)
std::atomic<int> data{0};
std::atomic<bool> ready{false};
int main() {
std::thread producer{[]{
data.store(42, std::memory_order_seq_cst);
ready.store(true, std::memory_order_seq_cst);
}};
std::thread consumer{[]{
while (!ready.load(std::memory_order_seq_cst)) { }
std::cout << data.load(std::memory_order_seq_cst);
}};
producer.join();
consumer.join();
42
117](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-117-320.jpg)
![Последовательная согласованность (sequential consistency)
std::atomic<int> z{0};
std::atomic<bool> x{false}, y{false};
int main(int argc, const char *argv[]) {
std::thread store_y{[]{
x.store(true, std::memory_order_seq_cst); }};
std::thread store_x{[]{
y.store(true, std::memory_order_seq_cst); }};
std::thread read_x_then_y{[]{
while (!x.load(std::memory_order_seq_cst)) { }
if (y.load(std::memory_order_seq_cst))
z.fetch_add(1, std::memory_order_seq_cst); }};
std::thread read_y_then_x{[]{
while (!y.load(std::memory_order_seq_cst)) { }
if (y.load(std::memory_order_seq_cst))
z.fetch_add(1, std::memory_order_seq_cst); }};
store_x.join(); store_y.join();
read_x_then_y.join(); read_y_then_x.join();
std::cout << z.load(std::memory_order_seq_cst);
z > 0
118](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-118-320.jpg)
![Ослабленное упорядочение (relaxed ordering)
std::atomic<int> data{0};
std::atomic<bool> ready{false};
int main() {
std::thread producer{[]{
data.store(42, std::memory_order_relaxed);
ready.store(true, std::memory_order_relaxed);
}};
std::thread consumer{[]{
while (!ready.load(std::memory_order_relaxed)) { }
std::cout << data.load(std::memory_order_relaxed);
}};
producer.join();
consumer.join();
42 не гарантируется
120](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-120-320.jpg)
![Ослабленное упорядочение (relaxed ordering)
std::atomic<int> z{0};
std::atomic<bool> x{false}, y{false};
int main(int argc, const char *argv[]) {
std::thread store_y{[]{
x.store(true, std::memory_order_relaxed); }};
std::thread store_x{[]{
y.store(true, std::memory_order_relaxed); }};
std::thread read_x_then_y{[]{
while (!x.load(std::memory_order_relaxed)) { }
if (y.load(std::memory_order_relaxed))
z.fetch_add(1, std::memory_order_relaxed); }};
std::thread read_y_then_x{[]{
while (!y.load(std::memory_order_relaxed)) { }
if (y.load(std::memory_order_relaxed))
z.fetch_add(1, std::memory_order_relaxed); }};
store_x.join(); store_y.join();
read_x_then_y.join(); read_y_then_x.join();
std::cout << z.load(std::memory_order_relaxed);
z >= 0
121](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-121-320.jpg)
![Метафора репозитория
1
кэш L1
2
кэш L1
Память
mov [x], 1
mov r1, [y]
mov [y], 1
mov r2, [x]
133](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-133-320.jpg)
![Метафора репозитория
1
2
Рекс
Мухтар
Центральный
репозиторий
mov [x], 1
x = 1
x = 0
Утечка данных из
центрального
репозитория в
локальный и обратно
x = 0
136](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-136-320.jpg)
![Метафора репозитория
1
2
Рекс
Мухтар
Центральный
репозиторий
mov [x], 1
x = 1
x = 1
Утечка данных из
центрального
репозитория в
локальный и обратно
x = 0
137](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-137-320.jpg)
![Метафора репозитория
1
2
Рекс
Мухтар
Центральный
репозиторий
mov [x], 1
x = 1
x = 1
Утечка данных из
центрального
репозитория в
локальный и обратно
x = 1
138](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-138-320.jpg)
![Метафора репозитория
1
2
Рекс
Мухтар
Центральный
репозиторий
mov [x], 1
x = 1
x = ?
x = ?
Неизвестно, когда
изменения распространятся
на другие потоки.
139](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-139-320.jpg)
![Метафора репозитория
1
2
Рекс
Мухтар
Центральный
репозиторий
mov [x], 1
mov r1, [y]
mov [y], 1
mov r2, [x]
x = 0
y = 0
x = 0
y = 0
x = 0
y = 0
140](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-140-320.jpg)
![Метафора репозитория
1
2
Рекс
Мухтар
Центральный
репозиторий
mov [x], 1
mov r1, [y]
mov [y], 1
mov r2, [x]
x = 0
y = 1
x = 1
y = 0
x = 0
y = 0
141](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-141-320.jpg)
![Метафора репозитория
1
2
Рекс
Мухтар
Центральный
репозиторий
mov [x], 1
mov r1, [y]
mov [y], 1
mov r2, [x]
x = ? {0,1}
y = 1
x = 1
y = ? {0,1}
x = ? {0,1}
y = ? {0,1}
142](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-142-320.jpg)
![Барьер LoadStore
1
Рекс
mov r1, [y]
mov r2, [x]
mov [z], 42
mov [w], r3
mov [v], r4
Операции загрузки
load
Операции сохранения
store
Переупорядочивание LoadStore
1. Есть набор инструкций, состоящий из операций
сохранения и загрузки.
148](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-148-320.jpg)
![Барьер LoadStore
1
Рекс
mov r1, [y]
mov r2, [x]
mov [z], 42
mov [w], r3
mov [v], r4
Операции загрузки
load - отложены
Операции сохранения
store - выполнены
Переупорядочивание LoadStore
1. Есть набор инструкций, состоящий из операций
сохранения и загрузки.
2. Если Рекс встречает операцию загрузки, то он
просматривает следующие операции сохранения,
и если они абсолютно не связаны с текущей
операцией загрузки, то он откладывает
выполнение операции загрузки и в первую
очередь выполняет операции сохранения. 149](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-149-320.jpg)
![Барьер LoadStore
1
Рекс
mov r1, [y]
mov r2, [x]
mov [z], 42
mov [w], r3
mov [v], r4
Будут промахи по
кэшу...
Будут попадания в
кэш...
Переупорядочивание LoadStore
1. Есть набор инструкций, состоящий из операций
сохранения и загрузки.
2. Если Рекс встречает операцию загрузки, которые
промахиваются по кэшу, то он просматривает следующие
операции сохранения, которые попадают в кэш, и если
они абсолютно не связаны с текущей операцией загрузки,
то он откладывает выполнение операции загрузки и в
первую очередь выполняет операции сохранения. 150](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-150-320.jpg)
![Барьер LoadStore
1
Рекс
mov r1, [y]
mov r2, [x]
LoadStore
mov [z], 42
mov [w], r3
mov [v], r4
Будут промахи по
кэшу...
Будут попадания в
кэш...
Переупорядочивание LoadStore
1. Есть набор инструкций, состоящий из операций
сохранения и загрузки.
2. Если Рекс встречает операцию загрузки, которые
промахиваются по кэшу, то он просматривает следующие
операции сохранения, которые попадают в кэш, и если
они абсолютно не связаны с текущей операцией загрузки,
то он откладывает выполнение операции загрузки и в
первую очередь выполняет операции сохранения. 151](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-151-320.jpg)
![Барьер StoreLoad
1
Рекс
mov [x], 1
mov r1, [y]
2
Мухтар
mov [y], 1
mov r2, [x]
x = 1
y = 0
x = 0
y = 1
r1 = 0
r2 = 0
152](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-152-320.jpg)
![Барьер StoreLoad
1
Рекс
mov [x], 1
StoreLoad
mov r1, [y]
2
Мухтар
mov [y], 1
StoreLoad
mov r2, [x]
x = 1
y = ?
x = ?
y = 1
Барьер StoreLoad:
▪ Гарантирует видимость для других
процессоров всех операций
сохранения, выполненных до
барьера.
▪ Обеспечивает для всех операций
загрузки, выполненных после
барьера, получение результатов,
которые имеют место во время
барьера.
▪ Барьер предотвращает r1 = r2 = 0
▪ StoreLoad ≠ StoreStore +
LoadLoad
153](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-153-320.jpg)
![Барьер StoreLoad
1
Рекс
mov [x], 1
StoreLoad
mov r1, [y]
x = 1
y = ?
Барьер StoreLoad (≠ StoreStore + LoadLoad):
1. Отправка (push) всех изменений в центральный репозиторий.
Центральный
репозиторий
154](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-154-320.jpg)
![Барьер StoreLoad
1
Рекс
mov [x], 1
StoreLoad
mov r1, [y]
x = 1
y = ?
Барьер StoreLoad (≠ StoreStore + LoadLoad):
1. Отправка (push) всех изменений в центральный репозиторий.
2. Ожидание завершения выполнения операции отправки (в
отличие от StoreStore, который может выполняться с задержкой).
Центральный
репозиторий
155](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-155-320.jpg)
![Барьер StoreLoad
1
Рекс
mov [x], 1
StoreLoad
mov r1, [y]
x = 1
y = ?
Барьер StoreLoad (≠ StoreStore + LoadLoad):
1. Отправка (push) всех изменений в центральный репозиторий.
2. Ожидание завершения выполнения операции отправки (в
отличие от StoreStore, который может выполняться с задержкой).
3. Загрузка (pull) всех последних изменений из центрального
репозитория (в отличие от LoadLoad, который не загружает
абсолютно последние изменения)
Центральный
репозиторий
156](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-156-320.jpg)
![std::vector<int> queue;
std::atomic<int> count;
void pop() {
for (auto i = 0; i < num_of_items; i++)
queue.push(i);
count.store(num_of_items, std::memory_order_release);
}
void consume() {
for (;;) {
auto item_index = count.fetch_sub(1, ?);
if (item_index <= 0) {
wait_for_items();
continue;
}
process(queue[item_index]);
}
}
Последовательность освобождений
193](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-193-320.jpg)
![std::vector<int> queue;
std::atomic<int> count;
void pop() {
for (auto i = 0; i < num_of_items; i++)
queue.push(i);
count.store(num_of_items, std::memory_order_release);
}
void consume() {
for (;;) {
auto item_index = count.fetch_sub(1,
std::memory_order_acquire);
if (item_index <= 0) {
wait_for_items();
continue;
}
process(queue[item_index]);
}
}
Последовательность освобождений
196](https://image.slidesharecdn.com/pct-spring2015-lec72-150525055103-lva1-app6891/85/2015-7-196-320.jpg)
ПВТ - весна 2015 - Лекция 7. Модель памяти С++. Внеочередное выполнение инструкций. Барьеры памяти. Атомарные операции
- 1. Лекция 7. Атомарные операции. Внеочередное выполнение инструкций. Барьеры памяти. Семантика захвата- освобождения. Модель памяти C++ Пазников Алексей Александрович Кафедра вычислительных систем СибГУТИ Сайт курса: http://cpct.sibsutis.ru/~apaznikov/teaching/ Вопросы: https://piazza.com/sibsutis.ru/fall2014/pct14/home Параллельные вычислительные технологии Осень 2014 (Parallel Computing Technologies, PCT 14)
- 3. Атомарные операции ▪ Операция над разделяемой переменной атомарная, если она выполняется потоком за один неделимый шаг. Ни один из других потоков не может обнаружить эту переменную в промежуточном состоянии. ▪ Если операции, которые совершают потоки над раздялемыми переменными, не атомарны, то это приведёт к гонкам данных. ▪ Гонки данных являются причиной неопредлённого поведения, поскольку они приводят к частичным (фрагментированным, “разорванным”) чтениям и записям переменных. 3
- 4. Фрагментированные чтения и записи uint64_t shared; int main() { shared = 0x100000002; ... 4
- 5. Фрагментированные чтения и записи mov DWORD PTR shared, 2 mov DWORD PTR shared+4, 1 uint64_t shared; int main() { shared = 0x100000002; ... gcc -m32 -S -masm=intel -O1 prog.c запись младших 32 бит запись старших 32 бит ▪ Выполнение присваивания 64-битного целого shared = 42 на 32-разрядной архитектуре выполняется за 2 инструкции. ▪ Операция записи не атомарная. 5
- 6. Фрагментированные чтения и записи mov DWORD PTR shared, 2 mov DWORD PTR shared+4, 1 uint64_t shared; int main() { shared = 0x100000002; ... gcc -m32 -S -masm=intel -O1 prog.c 1 поток запись старших 32 бит ▪ Вытеснение потока после записи младших бит приведёт к тому, что эти биты останутся в памяти и будут использованы другими потоками. ▪ На многоядерных системах даже не требуется вытеснения. 6
- 7. Фрагментированные чтения и записи mov DWORD PTR shared, 2 mov DWORD PTR shared+4, 1 uint64_t shared; int main() { shared = 0x100000002; ... gcc -m32 -S -masm=intel -O1 prog.c 1 поток 2 поток ▪ Вытеснение потока после записи младших бит приведёт к тому, что эти биты останутся в памяти, а старшие будут записаны другим потоком. ▪ На многоядерных системах даже не требуется вытеснения. 7
- 8. Фрагментированные чтения и записи mov eax, DWORD PTR shared mov edx, DWORD PTR shared+4 ret uint64_t shared; uint64_t getShared() { return shared; } gcc -m32 -S -masm=intel -O1 prog.c чтение младших 32 бит чтение старших 32 бит ▪ Выполнение чтения 64-битного целого shared на 32- разрядной архитектуре выполняется за 2 инструкции. ▪ Операция чтения не атомарная. 8
- 9. Фрагментированные чтения и записи strd r0, r1, [r2] ▪ Инструкции могут быть неатомарными, даже если выполняются одной процессорной инструкцией. Например, в ARMv7 инструкция для помещения содержимого двух 32-битных регистров в один 64-битный: На некоторых процессорах эта инструкция реализуются двумя отдельными операциями сохранения. 32-битная операция mov атомарна только для выравненных данных. В остальных случаях операция неатомарная ▪ Вытеснение потоков, выполняющих данные операции, или выполнение операций в двугих потоках в многоядерных системах приводит к неопределённому поведению. 9
- 10. Атомарность в С и С++ ▪ В языках С и С++ предполагается, что все операции неатомарны. ▪ Операции могут быть атомарными в большинстве случаев, например, операция присваивания 32-битного целого значения. ▪ Тем не менее, все инструкции должны рассматриваться как неатомарные. ▪ К счастью, в С и С++ есть набор шаблонов атомарных типов данных. 10
- 11. Атомарность в С и С++ ▪ Атомарные операции в С++ неделимы. Из любого потока нельзя обнаружить эту операцию выполненной частично - она либо выполнена, либо невыполнена. ▪ Это позволяет избежать гонок данных. ▪ Для атомарных типов определён метод is_lock_free, позволяющий определить, являются ли операции над ним напрямую с помощью атомарных инструкций, или они эмулируются. 11
- 12. Атомарные типы в С и С++ ▪ std::atomic_flag - единственный тип, который не имеет функции is_lock_free. Он предельно простой, всецело атомарный и поддерживает одну операцию: test_and_set - проверить и установить. ▪ Остальные типы определяются специализацией шаблона std::atomic<>, например std::atomic<int> и std:: atomic<void*> 12
- 13. Атомарные типы в С и С++ Атомарные тип Соответствующая специализация std::atomic_bool std::atomic<bool> std::atomic_char std::atomic<char> std::atomic_schar std::atomic<signed char> std::atomic_uchar std::atomic<unsigned char> std::atomic_short std::atomic<short> std::atomic_ushort std::atomic<unsigned short> std::atomic_int std::atomic<int> std::atomic_uint std::atomic<unsigned int> std::atomic_long std::atomic<long> ... + пользовательские типы 13
- 14. Операции над атомарными типами ▪ Операции сохранения: store, clear, etc. Упорядочение memory_order_relaxed, memory_order_release, memory_order_seq_cst. ▪ Операции загрузки: load, etc. Упорядочение memory_order_relaxed, memory_order_consume, memory_order_acquire, memory_order_seq_cst. ▪ Операции чтения-модификации-записи: compare_exchange, fetch_add, test_and_set, etc. Упорядочение memory_order_relaxed, memory_order_consume, memory_order_acquire, memory_order_release, memory_order_seq_cst, memory_order_acq_rel. 14
- 15. Атомарный флаг std::atomic_flag std::atomic_flag должен быть проиниализирован: std::atomic_flag flag = ATOMIC_FLAG_INIT Очистить флаг (операция сохранения): установить значение false: flag.clear(std::memory_order_release); Установить значение флага в true и вернуть предыдущее значение: bool x = flag.test_and_set(); Для атомарного флага запрещены операции копирования и присваивания. 15
- 16. Реализация спинлока на основе атомарного флага class spinlock_mutex { std::atomic_flag flag; public: spinlock_mutex(): flag{ATOMIC_FLAG_INIT} { } void lock() { while (flag.test_and_set( std::memory_order_acquire)); } void unlock() { flag.clear(std::memory_order_release); } }; n.b. spinlock_mutex можно использовать с lock_guard и unique_guard! 16 Записать в flag 1, вернуть то, что было Записать 0 в flag
- 17. Операции сохранения и загрузки атомарных типов // Объявить переменную и проициализировать true std::atomic<bool> b(true); // Загрузить значение в переменной в неатомарную // переменную x bool x = b.load(std::memory_order_acquire); // Записать в переменную b значение true b.store(true); // Обменять значение переменной b со значением false, // вернуть предыдущее значение b в переменную x. x = b.exchange(false, std::memory_order_acq_rel); 17
- 18. Операция “сравнить и обменять” Операция compare_exchange (“сравнить и обменять”): 1. Сравнить текущее значение атомарной переменной с ожидаемым expected. 2. Если значения совпали, сохранить новое значение desired и вернуть true. 3. Если значения не совпадают, то ожидаемое значение expected заменяется фактическим значением переменной, функция возвращает false. bool compare_exchange_weak(T& expected, T desired, std::memory_order order = std::memory_order_seq_cst); bool compare_exchange_strong(T& expected, T desired, std::memory_order order = std::memory_order_seq_cst); 18
- 19. Операция “сравнить и обменять” compare_exchange_weak() - сохранение может не произойти, даже если текущее значение совпадает с ожидаемым. Значение переменной не изменится, функция возвращает false. Последнее возможно при отсутствии аппаратной поддержки команды сравнить-и-обменять, из-за того, что поток может быть вытеснен в середине требуемой последовательности команд (ложный отказ). Из-за возможного ложного отказа функцию compare_exchange_weak() обычно вызывают в цикле: bool expected = false; extern atomic<bool> b; ... while (!b.compare_exchange_weak(expected, true); 19
- 20. Операция “сравнить и обменять” compare_exchange_strong() гарантирует замену переменной в случае выполнения условия. ▪ compare_exchange_strong() выгодно использовать в случае однократного выполнения операции, т.е. при необходимости заменить значение на жалаемое, и в случае, если вычисление нового значения занимает длительное время. ▪ Если функция compare_exchange вызывается в цикле, тогда предпочтительнее использовать compare_exchange_weak, чтобы избежать двойного цикла (compare_exchange_strong реализован в виде цикла на системах, которые не поддерживают атомарной операции сравнения и замены). 20
- 21. Атомарный тип atomic<T*> Функции для типа atomic<T*>: ▪ is_lock_free, load, store, exchange, compare_exchange_weak, compare_exchange_strong ▪ обменять и прибавить: fetch_add, operator++, operator+= ▪ обменять и вычесть: fetch_sub, operator--, operator-= class C {}; C arr[10]; std::atomic<C*> ptr(arr); C* x = ptr.fetch_add(2); assert(x == arr); assert(p.load() == &some_array[2]); p--; x = p; assert(x == &arr[1]); операции чтения- модификации- записи 21
- 22. Стандартные атомарные целочисленные типы Функции для типов стандартных атомарных целочисленных типов (int, unsigned int, long, unsigned long, etc): ▪ is_lock_free, load, store, exchange, compare_exchange_weak, compare_exchange_strong ▪ обменять и прибавить (fetch_add, operator++, operator+=) обменять и вычесть (fetch_sub, operator--, operator-=) ▪ operator&=, operator|=, operator^= Отсутствуют операции: ▫ умножения, деления, сдвига 22
- 23. Пользовательские атомарные типы В качестве шаблона std::atomic<> может выступать тип, он должен удовлетворять требованиям ▪ В нём должен присутствовать тривиальный оператор присваивания. Нет виртуальных функций и виртуальных базовых классов, а оператор присваивания генерируется автоматически (например, memcpy) ▪ Тип должен допускать побитовое сравнение на равенство (например, с помощью memcmp) 23
- 25. О дивный новый и прекрасный параллельный мир! Выполняет ли компьютер программу, которую вы написали? 25
- 26. О дивный новый и прекрасный параллельный мир! Выполняет ли компьютер программу, которую вы написали? НЕТ 26
- 27. О дивный новый и прекрасный параллельный мир! Выполняет ли компьютер программу, которую вы написали? НЕТПросто дело в том что... иерархическая структура памяти, внеочередное выполнение команд процессора и компиляторная оптимизация. 27
- 28. Аппаратно вызванные трансформации программы кэш 2 кэш 1 Память кэш 2 кэш 1 кэш 1 кэш 1 Процессорные ядра 28
- 29. Аппаратно вызванные трансформации программы кэш 2 кэш 1 Память кэш 2 кэш 1 кэш 1 кэш 1 Процессорные ядра Когерентность кэша (MESI, MOESI, MESIF) 29
- 30. Аппаратно вызванные трансформации программы кэш 2 кэш 1 Память кэш 2 кэш 1 кэш 1 кэш 1 Процессорные ядра Внеочередное выполнение инструкций (out- of-order execution) Когерентность кэша (MESI, MOESI, MESIF) 30
- 31. Аппаратно вызванные трансформации программы Intel Nehalem Core Pipeline 31
- 32. Аппаратно вызванные трансформации программы 32
- 33. Компиляторная оптимизация - виды оптимизаций ▪ Peephole-оптимизация ▪ Локальная оптимизация ▪ Внутрипроцедурная оптимизация ▪ Оптимизация циклов ▪ Межпроцедурная оптимизация 33
- 34. Компиляторная оптимизация - виды оптимизаций ▪ Peephole-оптимизация ▪ Локальная оптимизация ▪ Внутрипроцедурная оптимизация ▪ Оптимизация циклов ▫ Анализ индуктивных переменных ▫ Деление цикла на части ▫ Объединение циклов ▫ Инверсия цикла ▫ Расщепление цикла ▪ Межпроцедурная оптимизация 34
- 35. Компиляторная оптимизация - виды оптимизаций -O -fauto-inc-dec -fbranch-count-reg -fcombine-stack-adjustments -fcompare-elim -fcprop-registers -fdce -fdefer-pop -fdelayed-branch -fdse -fforward-propagate -fguess-branch-probability -fif-conversion2 -fif-conversion -finline-functions-called-once -fipa-pure-const -fipa-profile -fipa-reference -fmerge-constants -fmove-loop-invariants -fshrink-wrap -fsplit-wide-types -ftree-bit-ccp -ftree-ccp -fssa-phiopt -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-phiprop -ftree-sink -ftree-slsr -ftree-sra -ftree-pta -ftree-ter -funit-at-a-time -O2 -fauto-inc-dec -fbranch-count-reg -fcombine-stack-adjustments -fcompare-elim -fcprop-registers -fdce -fdefer-pop -fdelayed-branch -fdse -fforward-propagate -fguess-branch-probability -fif-conversion2 -fif-conversion -finline-functions-called-once -fipa-pure-const -fipa-profile -fipa-reference -fmerge-constants -fmove-loop-invariants -fshrink-wrap -fsplit-wide-types -ftree-bit-ccp -ftree-ccp -fssa-phiopt -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-phiprop -ftree-sink -ftree-slsr -ftree-sra -ftree-pta -ftree-ter -funit-at-a-time -fthread-jumps -falign-functions -falign- jumps -falign-loops -falign-labels -fcaller-saves -fcrossjumping -fcse-follow-jumps -fcse-skip- blocks -fdelete-null-pointer-checks -fdevirtualize -fdevirtualize- speculatively -fexpensive-optimizations -fgcse -fgcse-lm -fhoist-adjacent-loads -finline-small-functions -findirect-inlining -fipa-cp -fipa-sra -fipa-icf -fisolate-erroneous-paths- dereference -foptimize-sibling-calls -foptimize-strlen -fpartial-inlining -fpeephole2 -freorder-blocks -freorder- blocks-and-partition -freorder- functions -frerun-cse-after-loop -fsched-interblock -fsched- spec -fschedule-insns -fschedule- insns2 -fstrict-aliasing -fstrict- overflow -ftree-builtin-call-dce -ftree-switch-conversion - ftree-tail-merge -ftree-pre -ftree-vrp -fuse-caller-save -O3 -fauto-inc-dec -fbranch-count-reg -fcombine-stack-adjustments -fcompare-elim -fcprop-registers -fdce -fdefer-pop -fdelayed-branch -fdse -fforward-propagate -fguess-branch-probability -fif-conversion2 -fif-conversion -finline-functions-called-once -fipa-pure-const -fipa-profile -fipa-reference -fmerge-constants -fmove-loop-invariants -fshrink-wrap -fsplit-wide-types -ftree-bit-ccp -ftree-ccp -fssa-phiopt -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-phiprop -ftree-sink -ftree-slsr -ftree-sra -ftree-pta -ftree-ter -funit-at-a-time -fthread-jumps -falign-functions -falign-jumps -falign-loops -falign-labels -fcaller-saves -fcrossjumping -fcse-follow-jumps -fcse-skip- blocks -fdelete-null-pointer-checks -fdevirtualize -fdevirtualize- speculatively -fexpensive-optimizations -fgcse -fgcse-lm -fhoist-adjacent-loads -finline-small-functions -findirect-inlining -fipa-cp -fipa-sra -fipa-icf -fisolate-erroneous-paths- dereference -foptimize-sibling-calls -foptimize-strlen -fpartial-inlining -fpeephole2 -freorder-blocks -freorder-blocks- and-partition -freorder-functions -frerun-cse-after-loop -fsched-interblock -fsched-spec -fschedule-insns -fschedule-insns2 -fstrict-aliasing -fstrict-overflow -ftree-builtin-call-dce -ftree-switch-conversion -ftree- tail-merge -ftree-pre -ftree-vrp -fuse-caller-save -finline-functions -funswitch-loops -fpredictive-commoning -fgcse-after-reload -ftree-loop-vectorize -ftree-loop-distribute-patterns -ftree-slp-vectorize -fvect-cost-model -ftree-partial-pre -fipa-cp-clone 35
- 36. Компиляторная оптимизация - примеры оптимизаций x = 1; y = 2; x = 3; for (i = 0; i < n; i++) sum += a[i]; y = 2; x = 3; r1 = sum; for (i = 0; i < n; i++) r1 += a[i]; sum = r1; for (i = 0; i < n; i++) j = 42 * i; j = -42 for (i = 0; i < n; i++) j = j + 42; 36
- 37. Компиляторная оптимизация - примеры оптимизаций x = Johann; y = Sebastian; z = Bach; for (i = 0; i < n; i++) for (j = 0; j < m;j++); a[i][j] = 1; z = Bach; x = Johann; y = Sebastian; for (j = 0; j < n; j++) for (i = 0; i < m; i++); a[i][j] = 1; for (i = 0; i < n; i++) a[i] = 1; for (i = 0; i < n; i++) b[i] = 2; for (i = 0; i < n; i++) { a[i] = 1; b[i] = 2; } 37
- 38. Компиляторная оптимизация - примеры оптимизаций Что компилятор знает: Все операции с памятью совершаются в текущем потоке, что они в точности означают, и какие существуют зависимости по данным. Что компилятор не знает: Какие области памяти доступны и изменяются в разных потоках. Как решить: Сказать! Как-то пометить операции, которые выполняются с разделяемыми переменными. 38
- 39. Этапы трансформации программы Исходный код Компилятор удаление подвыражений, свёртка констант, оптимизация циклов, ... Процессор предвыборка, спекулятивное выполнение инструкций, буферизация, HTM, ... Реальное выполнение программы Кэш частные и общие кэши, буферы записи, ... “Гораздо лучше выполнять другую программу - не ту, что вы написали. Вам на самом деле даже не хочется выполнять эту вашу чушь - вы хотите запускать другую программу! Всё это делается для вашего блага.” 39
- 40. Этапы трансформации программы ▪ Как правило нельзя определить, на каком уровне произошла трансформация. ▪ Трансформации на всех уровнях эквивалентны, что позволяет рассматривать их как переупорядочивание операций загрузки (loads) и записи (stores). ▪ Необходимое условие при выполнении трансформаций - сохранение иллюзии последовательно согласованного кода. 40 Исходный код Компилятор удаление подвыражений, свёртка констант, оптимизация циклов, ... Процессор предвыборка, спекулятивное выполнение инструкций, буферизация, HTM, ... Реальное выполнение программы Кэш частные и общие кэши, буферы записи, ...
- 41. Последовательная согласованность (sequential consistency, SC) “Результат выполнения программы такой, как если бы операции всех процессоров выполнялись последовательно и результат операции каждого отдельного процессора появлялся бы в этой последовательности в порядке, который определяется программой.” (Л. Лэмпорт, 1979) ▪ Рассмотрим многопроцессорную систему, состоящую из нескольких последовательных процессоров. ▪ Операции, выполняемые процессорами над некоторой областью памяти (страница, объект, адрес, ...), появляются в одном и том же порядке для всех процессоров, несмотря на то, что фактическая последовательность выполнения операций может быть другой. 41
- 42. Последовательная согласованность (sequential consistency, SC) “Результат выполнения программы такой, как если бы операции всех процессоров выполнялись последовательно и результат операции каждого отдельного процессора появлялся бы в этой последовательности в порядке, который определяется программой.” (Л. Лэмпорт, 1979) ▪ Рассмотрим многопроцессорную систему, состоящую из нескольких последовательных процессоров. ▪ Операции, выполняемые процессорами над некоторой областью памяти (страница, объект, адрес, ...), появляются в одном и том же порядке для всех процессоров, несмотря на то, что фактическая последовательность выполнения операций может быть другой. И это прекрасно! 42
- 43. Последовательная согласованность (sequential consistency, SC) “Результат выполнения программы такой, как если бы операции всех процессоров выполнялись последовательно и результат операции каждого отдельного процессора появлялся бы в этой последовательности в порядке, который определяется программой.” (Л. Лэмпорт, 1979) ▪ Рассмотрим многопроцессорную систему, состоящую из нескольких последовательных процессоров. ▪ Операции, выполняемые процессорами над некоторой областью памяти (страница, объект, адрес, ...), появляются в одном и том же порядке для всех процессоров, несмотря на то, что фактическая последовательность выполнения операций может быть другой. И это прекрасно! но...43
- 44. Последовательная согласованность (sequential consistency, SC) … но вы этого не хотите! ▪ Скорее всего очень нерационально выполнять в точности то, что вы написали. ▪ Гораздо лучше выполнить нечто иное, которое бы работало так же, как и то, что вы написали, но выполнялось бы гораздо быстрее. Поэтому ▪ Мы (программное обеспечение ПО: компилятор и аппаратное обеспечение АО: кэш, процессор) будем это делать! ▪ А вы (программисты), в свою очередь, должны обеспечить возможность корректной трансформации и выполнения программы так, чтобы сохранялась иллюзия последовательной согласованности, включив в свою программу необходимые ограничения. 44
- 45. Модель памяти - это договор Вы обещаете Корректно реализовать синхронизацию в вашей программе (путём добавления необходимых инструкций в программу, делающих её безопасной относительно гонок) Система обещает Обеспечить иллюзию выполнения той программы, которую вы написали. (путём компиляции и выполнения) 45
- 46. Модель памяти - это договор Вы обещаете Корректно реализовать синхронизацию в вашей программе (путём добавления необходимых инструкций в программу, делающих её безопасной относительно гонок) Система обещает Обеспечить иллюзию выполнения той программы, которую вы написали. (путём компиляции и выполнения) Модель памяти определяет, какие действия вы должны совершить и как должна отреагировать система, чтобы обеспечить выполнение операций с памятью в необходимой последовательности. 46
- 48. Аппаратное переупорядочивание инструкций Первое правило робототехники компиляторов и процессоров при упорядочивании доступа к памяти: Нельзя изменять поведение однопоточной программы. ▪ В однопоточных программах переупорядочивания остаются незамеченными. ▪ То же самое - при многопоточном программировании на основе мьютексов, семафоров и т.д. ▪ Но не при использовании атомарных переменных и техник программирования без блокировок. 48
- 49. Переупорядочивание на примере алгоритма Деккера Поток 1 flag1 = 1; if (flag2 != 0) // ожидать освобождения // критической секции else // войти в критическую // секцию Алгоритм Деккера позволяет решать проблему взаимного исключения (в теории), был опубликован в 1965 г. Он не приводит к взаимным исключениям (deadlock) и свободен от голодания (starvation). Поток 2 flag2 = 1; if (flag1 != 0) // ожидать освобождения // критической секции else // войти в критическую // секцию 49
- 50. Переупорядочивание на примере алгоритма Деккера Процессор 1 Процессор 2 flag2 = 1; if (flag1 != 0) { … } Память: flag1 = 0, flag2 = 0 flag1 = 1; if (flag2 != 0) { … } Store Buffer Store Buffer 50
- 51. Переупорядочивание на примере алгоритма Деккера Процессор 1 Процессор 2 Память: flag1 = 0, flag2 = 0 flag1 = 1; if (flag2 != 0) { … } flag2 = 1; if (flag1 != 0) { … } Store Buffer flag1 = 1 Store Buffer Сохранение 1 в буфере 51
- 52. Переупорядочивание на примере алгоритма Деккера Процессор 1 Процессор 2 Память: flag1 = 0, flag2 = 0 flag1 = 1; if (flag2 != 0) { … } flag2 = 1; if (flag1 != 0) { … } Store Buffer flag1 = 1 Сохранение 1 в буфере Сохранение 1 в буфере Store Buffer flag1 = 1 52
- 53. Переупорядочивание на примере алгоритма Деккера Процессор 1 Процессор 2 Память: flag1 = 0, flag2 = 0 flag1 = 1; if (flag2 != 0) { … } flag2 = 1; if (flag1 != 0) { … } Store Buffer flag1 = 1 Сохранение 1 в буфере Сохранение 1 в буфере Store Buffer flag1 = 1 Чтение 0 для flag2 Чтение 0 для flag1 StoreLoad 53
- 54. Переупорядочивание на примере алгоритма Деккера Процессор 1 Процессор 2 Память: flag1 = 0, flag2 = 0 flag1 = 1; if (flag2 != 0) { … } flag2 = 1; if (flag1 != 0) { … } Store Buffer flag1 = 1 Сохранение 1 в буфере Сохранение 1 в буфере Store Buffer flag1 = 1 Чтение 0 для flag2 Чтение 0 для flag1 54
- 55. Переупорядочивание на примере алгоритма Деккера Процессор 1 Процессор 2 Память: flag1 = 1, flag2 = 1 flag1 = 1; if (flag2 != 0) { … } flag2 = 1; if (flag1 != 0) { … } Store Buffer flag1 = 1 Сохранение 1 в буфере Сохранение 1 в буфере Store Buffer flag1 = 1 Чтение 0 для flag2 Чтение 0 для flag1 Сброс буфера (flag1) Сброс буфера (flag2) 55
- 56. Переупорядочивание в различных процессорах Тип переупоря- дочивания / архитектуры Alpha ARMv7 POWER SPARC RMO SPARC PSO SPARC TSO x86 AMD64 IA-64 Loads после loads Loads после stores Stores после stores Stores после loads АО с loads АО с stores Зависимые loads АО - атомарные операции 56
- 57. Переупорядочивание в различных процессорах IBM Blue Gene Смартфоны DEC Alpha Xbox 360 PowerPC ARM SPARC TSO x86 / 64 более сильное упорядочивание (strong model, sequential consistency) более слабое упорядочивание (weak model, relaxed ordering) Как правило сильное упорядочивание Ослабленное упорядочивание с поддержкой зависимостей по данным Вполне ослабленное упорядочивание PowerMac 57
- 58. Переупорядочивание в различных процессорах IBM Blue Gene Смартфоны DEC Alpha Xbox 360 PowerPC ARM SPARC TSO x86 / 64 более сильное упорядочивание (strong model, sequential consistency) более слабое упорядочивание (weak model, relaxed ordering) Как правило сильное упорядочивание Ослабленное упорядочивание с поддержкой зависимостей по данным Вполне ослабленное упорядочивание PowerMac При сильном упорядочивании (сильная модель памяти) каждая инструкция неявно реализует семантику захвата и освобождения. При слабом упорядочивании (слабая модель памяти) не накладывается никаких ограничений на порядок выполнения инструкций. 58
- 59. Переупорядочивание в процессорах архитектуры x86 IBM Blue Gene Смартфоны DEC Alpha Xbox 360 PowerPC ARM SPARC TSO x86 / 64 более сильное упорядочивание (strong model, sequential consistency) более слабое упорядочивание (weak model, relaxed ordering) Как правило сильное упорядочивание Ослабленное упорядочивание с поддержкой зависимостей по данным Вполне ослабленное упорядочивание PowerMac 59
- 60. Переупорядочивание в процессорах архитектуры x86 Intel Architectures Software Developer’s Manual, Vol. 3: ▪ Операции чтения не могут быть переупорядочены с другими операциями чтения ▪ Операции записи не могут быть переупорядочены с другими операциями записями ▪ Операции записи не могут быть переупорядочены с другими операциями записи, кроме следующих исключений: … ▪ Операции чтения могут быть переупорядочены с более старыми операциями записи в другие области памяти, но не с операциями записи в ту же область. ▪ Операции чтения не могут перейти раньше инструкций LFENCE, MFENCE, операции записи - раньше инструкций LFENCE, SFENCE, MFENCE. ▪ LFENCE, SFENCE, MFENCE не могут выполниться раньше операций чтения, записи, того или другого соответственно. 60
- 61. Переупорядочивание в процессорах архитектуры x86 Процессор 1 mov x, 1 ; запись (store) ; 1 в x mov r1, y ; загрузка (load) ; из y в регистр Процессор 2 mov y, 1 ; запись (store) ; 1 в x mov r2, x ; загрузка (load) ; из y в регистр Возможные варианты: ▪ r1 = 0, r2 = 1 ▪ r1 = 1, r2 = 0 ▪ r1 = 1, r2 = 1 ▪ r1 = 0, r2 = 0 x = 0, y = 0 61
- 62. Переупорядочивание в процессорах архитектуры x86 Процессор 1 mov x, 1 ; запись (load) ; 1 в x mov r1, y ; загрузка (store) ; из y в регистр Процессор 2 mov y, 1 ; запись (load) ; 1 в x mov r2, x ; загрузка (store) ; из y в регистр ▪ r1 = 0, r2 = 0 В процессорах архитектуры x86 достустима перестановка операция load после store. Или, то же, операции store могут выполняться до операций load. x = 0, y = 0 StoreLoad 62
- 63. Переупорядочивание в процессорах архитектуры x86 Поток 1 x = 1; asm volatile("" ::: "memory"); r1 = y; Программный барьер памяти: запретить переупорядочивание инструкций компилятором. 63
- 64. Переупорядочивание в процессорах архитектуры x86 Поток 1 x = 1; asm volatile("" ::: "memory"); r1 = y; Поток 3 if (r1 == 0 && r2 == 0) printf("reordering happened!n"); Поток 2 y = 1; asm volatile("" ::: "memory"); r2 = x; 64 Переупорядочивание может произойти!
- 65. Переупорядочивание в процессорах архитектуры x86 Поток 1 x = 1; asm volatile("" ::: "memory"); r1 = y; Поток 3 if (r1 == 0 && r2 == 0) printf("reordering happened!n"); Поток 2 y = 1; asm volatile("" ::: "memory"); r2 = x; 65
- 66. Переупорядочивание в процессорах архитектуры x86 Поток 1 x = 1; asm volatile("mfence" ::: "memory"); asm volatile("" ::: "memory"); r1 = y; Поток 2 y = 1; asm volatile("mfence" ::: "memory"); asm volatile("" ::: "memory"); r2 = x; Поток 3 if (r1 == 0 && r2 == 0) printf("reordering happened!n"); 66
- 67. Переупорядочивание в процессорах архитектуры x86 Поток 1 x = 1; asm volatile("mfence" ::: "memory"); asm volatile("" ::: "memory"); r1 = y; Программный барьер памяти: запретить переупорядочивание инструкций компилятором. Аппаратный барьер памяти: запретить переупорядочивание инструкций процессором. 67 mov DWORD PTR X[rip], 1 mfence mov eax, DWORD PTR Y[rip] ... mov DWORD PTR r1[rip], eax полный барьер памяти
- 68. Переупорядочивание в процессорах архитектуры x86 Поток 1 x = 1; asm volatile("mfence" ::: "memory"); asm volatile("" ::: "memory"); r1 = y; Поток 3 if (r1 == 0 && r2 == 0) printf("reordering happened!n"); Переупорядочивание не произойдёт! Поток 2 y = 1; asm volatile("mfence" ::: "memory"); asm volatile("" ::: "memory"); r2 = x; 68
- 69. Переупорядочивание в процессорах с ослабленным упорядочиванием IBM Blue Gene Смартфоны DEC Alpha Xbox 360 PowerPC ARM SPARC TSO x86 / 64 более сильное упорядочивание (strong model, sequential consistency) более слабое упорядочивание (weak model, relaxed ordering) Как правило сильное упорядочивание Ослабленное упорядочивание с поддержкой зависимостей по данным Вполне ослабленное упорядочивание PowerMac 69
- 70. Переупорядочивание в процессорах с ослабленным упорядочиванием Для ослабленного упорядочивания характерно то, что одно ядро может видеть изменения в общей памяти в порядке, отличном от порядка, в котором другое ядро вносит изменения. int sharedCount; // глобальный счётчик void IncShared() { int count = 0; // локальный счётчик while (count < N) { randomBusyWork(); // случайная задержка // наивная реализация мьютекса int expected = 0; if (flag.compare_exchange_strong(expected, 1, std::memory_order_relaxed)); { sharedVal++; // выполняется под защитой мьютекса flag.store(0, std::memory_order_relaxed)) count++; } } 70
- 71. Переупорядочивание в процессорах с ослабленным упорядочиванием Для ослабленного упорядочивания характерно то, что одно ядро может видеть изменения в общей памяти в порядке, отличном от порядка, в котором другое ядро вносит изменения. int sharedCount; // глобальный счётчик void IncShared() { int count = 0; // локальный счётчик while (count < N) { randomBusyWork(); // случайная задержка // наивная реализация мьютекса int expected = 0; if (flag.compare_exchange_strong(expected, 1, std::memory_order_relaxed)); { sharedVal++; // выполняется под защитой мьютекса flag.store(0, std::memory_order_relaxed)) count++; } } StoreStore 71
- 72. int sharedCount; // глобальный счётчик void IncShared() { int count = 0; // локальный счётчик while (count < N) { randomBusyWork(); // случайная задержка // наивная реализация мьютекса int expected = 0; if (flag.compare_exchange_strong(expected, 1, std::memory_order_relaxed)); { sharedVal++; // выполняется под защитой мьютекса asm volatile("" ::: "memory"); flag.store(0, std::memory_order_relaxed)) count++; } } StoreStore Переупорядочивание в процессорах с ослабленным упорядочиванием Для ослабленного упорядочивания характерно то, что одно ядро может видеть изменения в общей памяти в порядке, отличном от порядка, в котором другое ядро вносит изменения. запрет компиляторного переупорядочивания 72
- 73. Переупорядочивание в процессорах с ослабленным упорядочиванием Поток 1 int sharedCount; void IncShared() { int count = 0; while (count < N) { randomBusyWork(); int expected = 0; if (...) { sharedVal++; asm volatile(...); flag.store(0, ...) count++; } } Поток 2 int sharedCount; void IncShared() { int count = 0; while (count < N) { randomBusyWork(); int expected = 0; if (...) { sharedVal++; asm volatile(...); flag.store(0, ...) count++; } } 73
- 74. Переупорядочивание в процессорах с ослабленным упорядочиванием Поток 1 int sharedCount; void IncShared() { int count = 0; while (count < N) { randomBusyWork(); int expected = 0; if (...) { sharedVal++; asm volatile(...); (1) flag.store(0, ...); count++; } } Поток 2 int sharedCount; void IncShared() { int count = 0; while (count < N) { randomBusyWork(); int expected = 0; if (...) { sharedVal++; asm volatile(...); flag.store(0, ...) count++; } } 74
- 75. Переупорядочивание в процессорах с ослабленным упорядочиванием Поток 1 int sharedCount; void IncShared() { int count = 0; while (count < N) { randomBusyWork(); int expected = 0; if (...) { (2) sharedVal++; asm volatile(...); (1) flag.store(0, ...); count++; } } Поток 2 int sharedCount; void IncShared() { int count = 0; while (count < N) { randomBusyWork(); int expected = 0; if (...) { (3) sharedVal++; asm volatile(...); flag.store(0, ...) count++; } } 75
- 76. Переупорядочивание в процессорах с ослабленным упорядочиванием $ ./prog 100000 // N = 100000 sharedCount = 199348 sharedCount = 199034 sharedCount = 199517 sharedCount = 199829 sharedCount = 199113 sharedCount = 199566 Допустим N = 100000 Каждый из 2 потоков выполняет 100000 операций инкремента разделяемой переменной sharedCount++. Ожидаемое значение: sharedVal = 200000 В реальности: 76
- 77. Переупорядочивание при выполнении операция захвата-освобождения в процессорах архитектуры POWER Поток 1 (процессор 1) // Подготавливаем данные // и устанавливаем флаг // готовности for (i = 0; i < n; i++) { widget[i].x = x; widget[i].y = y; widget[i].ready = true; } Поток 2 (процессор 2) // Если данные готовы, // обрабатываем их for (i = 0; i < n; i++) { if (widget[i].ready) { do_some_stuff(widget[i]); } } L2-кэш Буфер 1 Буфер 2 Буфер N ... ... 77
- 78. Переупорядочивание при выполнении операция захвата-освобождения в процессорах архитектуры POWER Поток 1 (процессор 1) // Подготавливаем данные // и устанавливаем флаг // готовности for (i = 0; i < n; i++) { widget[i].x = x; widget[i].y = y; widget[i].ready = true; } Поток 2 (процессор 2) // Если данные готовы, // обрабатываем их for (i = 0; i < n; i++) { if (widget[i].ready) { do_some_stuff(widget[i]); } } L2-кэш Буфер 1 Буфер 2 Буфер N ... ... 78
- 79. Переупорядочивание при выполнении операция захвата-освобождения в процессорах архитектуры POWER Поток 1 (процессор 1) // Подготавливаем данные // и устанавливаем флаг // готовности for (i = 0; i < n; i++) { widget[i].x = x; widget[i].y = y; widget[i].ready = true; } Поток 2 (процессор 2) // Если данные готовы, // обрабатываем их for (i = 0; i < n; i++) { if (widget[i].ready) { do_some_stuff(widget[i]); } } L2-кэш Буфер 1 Буфер 2 Буфер N ... ... 79
- 80. Переупорядочивание при выполнении операция захвата-освобождения в процессорах архитектуры POWER Поток 1 (процессор 1) // Подготавливаем данные // и устанавливаем флаг // готовности for (i = 0; i < n; i++) { widget[i].x = x; widget[i].y = y; widget[i].ready = true; } Поток 2 (процессор 2) // Если данные готовы, // обрабатываем их for (i = 0; i < n; i++) { if (widget[i].ready) { do_some_stuff(widget[i]); } } L2-кэш Буфер 1 Буфер 2 Буфер N ... ... 80
- 81. Переупорядочивание при выполнении операция захвата-освобождения в процессорах архитектуры POWER Поток 1 (процессор 1) // Подготавливаем данные // и устанавливаем флаг // готовности for (i = 0; i < n; i++) { widget[i].x = x; widget[i].y = y; widget[i].ready = true; } Поток 2 (процессор 2) // Если данные готовы, // обрабатываем их for (i = 0; i < n; i++) { if (widget[i].ready) { do_some_stuff(widget[i]); } } L2-кэш: widget[i].y = y; widget[i].ready = true; ... ... 81
- 82. Переупорядочивание при выполнении операция захвата-освобождения в процессорах архитектуры POWER Поток 1 (процессор 1) // Подготавливаем данные // и устанавливаем флаг // готовности for (i = 0; i < n; i++) { widget[i].x = x; widget[i].y = y; widget[i].ready = true; } Поток 2 (процессор 2) // Если данные готовы, // обрабатываем их for (i = 0; i < n; i++) { if (widget[i].ready) { do_some_stuff(widget[i]); } } L2-кэш: widget[i].y = y; widget[i].ready = true; ... ... StoreStore 82
- 84. Программное переупорядочивание инструкций Первое правило робототехники компиляторов и процессоров при упорядочивании доступа к памяти: Нельзя изменять поведение однопоточной программы. ▪ В однопоточных программах переупорядочивания остаются незамеченными. ▪ То же самое - при многопоточном программировании на основе мьютексов, семафоров и т.д. ▪ Но не при использовании атомарных переменных и техник программирования без блокировок. 84
- 85. Программное переупорядочивание инструкций mov eax, DWORD PTR y[rip] add eax, 111 mov DWORD PTR x[rip], eax mov DWORD PTR y[rip], 222 int x, y; int main() { x = y + 111; y = 222; printf("%d%d", x, y); gcc -S -masm=intel prog.c выполнение команды x = y + 111 завершено выполнение команды y = 222 завершено 85
- 86. Программное переупорядочивание инструкций mov eax, DWORD PTR y[rip] mov edx, 222 ... mov DWORD PTR y[rip], 222 lea esi, [rax+111] ... mov DWORD PTR x[rip], esi int x, y; int main() { x = y + 111; y = 222; printf("%d%d", x, y); gcc -S -masm=intel -O2 prog.c выполнение команды y = 222 завершено выполнение команды x = y + 111 завершено y = 222 выполняется раньше x = y + 111 86
- 87. Программное переупорядочивание инструкций mov eax, DWORD PTR y[rip] add eax, 111 mov DWORD PTR x[rip], eax mov esi, DWORD PTR x[rip] mov edx, 222 ... xor eax, eax mov DWORD PTR y[rip], 222 int x, y; int main() { x = y + 111; asm volatile("" ::: "memory"); y = 222; printf("%d%d", x, y); gcc -S -masm=intel -O2 prog.c явный барьер 87
- 88. Программное переупорядочивание инструкций на примере с публикацией данных (операция захвата-освобождения) int data; bool isReleased = false; // данные опубликованы? void releaseData(int val) // опубликовать данные { data = val; // записать данные isReleased = true; // данные опубликованы! } // можно с ними работать 88
- 89. Программное переупорядочивание инструкций на примере с публикацией данных (операция захвата-освобождения) Поток 1 int data; bool isReleased = false; void releaseData(int val) { data = val; isReleased = true; } Поток 2 void utilizeData() { while (!isReleased); doSomething(data); } Данные должны быть проинициализированы в 1 потоке перед тем, как они будут использованы во 2 потоке. 89
- 90. Программное переупорядочивание инструкций на примере с публикацией данных (операция захвата-освобождения) Поток 1 int data; bool isReleased = false; void releaseData(int val) { data = val; isReleased = true; } Поток 2 void utilizeData() { while (!isReleased); doSomething(data); } 1. Данные проиницаилизрованы 90
- 91. Программное переупорядочивание инструкций на примере с публикацией данных (операция захвата-освобождения) Поток 1 int data; bool isReleased = false; void releaseData(int val) { data = val; isReleased = true; } Поток 2 void utilizeData() { while (!isReleased); doSomething(data); } 1. Данные проициализированы 2. Ура! Второй поток может обрабатывать 91
- 92. Программное переупорядочивание инструкций на примере с публикацией данных (операция захвата-освобождения) Поток 1 int data; bool isReleased = false; void releaseData(int val) { data = val; isReleased = true; } Поток 2 void utilizeData() { while (!isReleased); doSomething(data); } 92
- 93. Программное переупорядочивание инструкций на примере с публикацией данных (операция захвата-освобождения) Поток 1 int data; bool isReleased = false; void releaseData(int val) { data = val; isReleased = true; } Поток 2 void utilizeData() { while (!isReleased); doSomething(data); } Из-за переупорядочивания инструкций компилятором флаг выставляется до того, как данные готовы. 93 StoreStore
- 94. Программное переупорядочивание инструкций на примере с публикацией данных (операция захвата-освобождения) Поток 1 int data; bool isReleased = false; void releaseData(int val) { data = val; isReleased = true; } Поток 2 void utilizeData() { while (!isReleased); doSomething(data); } Из-за переупорядочивания инструкций компилятором флаг выставляется до того, как данные готовы. StoreStore 94
- 95. Программное переупорядочивание инструкций на примере с публикацией данных (операция захвата-освобождения) Поток 1 int data; bool isReleased = false; void releaseData(int val) { data = val; isReleased = true; } Поток 2 void utilizeData() { while (!isReleased); doSomething(data); } Из-за переупорядочивания инструкций компилятором флаг выставляется до того, как данные готовы. 95
- 96. Программное переупорядочивание инструкций на примере с публикацией данных (операция захвата-освобождения) Поток 1 int data; bool isReleased = false; void releaseData(int val) { data = val; isReleased = true; } Поток 2 void utilizeData() { while (!isReleased); doSomething(data); } 96
- 97. Программное переупорядочивание инструкций на примере с публикацией данных (операция захвата-освобождения) Поток 1 int data; bool isReleased = false; void releaseData(int val) { data = val; asm volatile("" ::: "memory"); isReleased = true; } Поток 2 void utilizeData() { while (!isReleased); asm volatile("" ::: "memory"); doSomething(data); } 97
- 98. Программное переупорядочивание инструкций на примере с публикацией данных (операция захвата-освобождения) Поток 1 int data; bool isReleased = false; void releaseData(int val) { data = val; asm volatile("" ::: "memory"); isReleased = true; } Поток 2 void utilizeData() { while (!isReleased); asm volatile("" ::: "memory"); doSomething(data); } Операция записи- освобождения Операция чтения- захвата 98
- 99. Операции сохранения из чистого воздуха (out-of-thin air stores) if (x > 0) y++; register int r = y; if (x > 0) r++; y = r; Размещение переменной в регистре в процессе оптимизирующей компиляции создание новой регистровой переменной Новая операция сохранения (store) “из чистого воздуха” Создание операций сохранения “из чистого воздуха” не допустимо в соответствии с последним стандартом, однако... 99
- 100. Операции сохранения из чистого воздуха (out-of-thin air stores) static pthread_mutex_t lock = PTHREAD_MUTEX_INITALIZER; static int count = 0; int trylock() { int rc; rc = pthread_mutex_trylock(&mutex); if (rc == 0) count++; однако в С & PThreads такая оптимизация допускается: static int count = 0; int trylock() { register int r = count; int rc; rc = pthread_mutex_trylock(&mutex); if (rc == 0) count++; count = r; новый store и новая гонка данных! 100
- 102. Отношение happens-before (происходит-раньше) Отношение happens-before определяет, какие операции видят последствия других операций. Допустим A и В - операции в многопоточной программе. Тогда если А происходит-раньше В, тогда эффект (результат операции, который отразился в памяти) операции А становится видим для потока, выполняющего операцию В. x = 10; // A y = x + 1; // B 102
- 103. Отношение happens-before (происходит-раньше) Отношение happens-before определяет, какие операции видят последствия других операций. Допустим A и В - операции в многопоточной программе. Тогда если А происходит-раньше В, тогда эффект (результат операции, который отразился в памяти) операции А становится видим для потока, выполняющего операцию В. x = 10; y = x + 1; z = sqrt(x * y); Все соотношения happens-before для операции А (x = 10) 103
- 104. x = 10; y = x + 1; z = sqrt(x * y); m = k - 5; print(m) print(x) Отношение happens-before (происходит-раньше) Отношение happens-before определяет, какие операции видят последствия других операций. Допустим A и В - операции в многопоточной программе. Тогда если А происходит-раньше В, тогда эффект (результат операции, который отразился в памяти) операции А становится видим для потока, выполняющего операцию В. 104
- 105. Поток 1 Поток 2 x = 10; y = x + 1; z = sqrt(x * y); m = k - 5; print(m) w = x + 2 Отношение happens-before (происходит-раньше) Отношение happens-before определяет, какие операции видят последствия других операций. Допустим A и В - операции в многопоточной программе. Тогда если А происходит-раньше В, тогда эффект (результат операции, который отразился в памяти) операции А становится видим для потока, выполняющего операцию В. 105
- 106. Отношение happens-before определяет, какие операции видят последствия других операций. Допустим A и В - операции в многопоточной программе. Тогда если А происходит-раньше В, тогда эффект (результат операции, который отразился в памяти) операции А становится видим для потока, выполняющего операцию В. Происходит-раньше ≠ происходит раньше 1. Из того, что А происходит-раньше В не следует, что А происходит раньше В. 2. Из того, что А происходит раньше В не следует, что А происходит-раньше В 106
- 107. Происходит-раньше не означает происходит раньше int x, y; int main() { x = y + 111; // A y = 222; // B printf("%d%d", x, y); 1. Из того, что А происходит-раньше В не следует, что А происходит раньше В. 107
- 108. Происходит-раньше не означает происходит раньше mov eax, DWORD PTR y[rip] mov edx, 222 ... mov DWORD PTR y[rip], 222 lea esi, [rax+111] ... mov DWORD PTR x[rip], esi int x, y; int main() { x = y + 111; // A y = 222; // B printf("%d%d", x, y); gcc -S -masm=intel -O2 prog.c 1. Из того, что А происходит-раньше В не следует, что А происходит раньше В. 108
- 109. Происходит-раньше не означает происходит раньше mov eax, DWORD PTR y[rip] mov edx, 222 ... mov DWORD PTR y[rip], 222 lea esi, [rax+111] ... mov DWORD PTR x[rip], esi int x, y; int main() { x = y + 111; y = 222; printf("%d%d", x, y); gcc -S -masm=intel -O2 prog.c выполнение команды y = 222 завершено выполнение команды x = y + 111 завершено y = 222 выполняется раньше x = y + 111 1. Из того, что А происходит-раньше В не следует, что А происходит раньше В. 109
- 110. Происходит раньше не означает происходит-раньше 2. Из того, что А происходит раньше В не следует, что А происходит-раньше В Поток 2 if (ready) // B print(x); Поток 1 x = 42 ready = true; // A int x; bool ready = false; 110
- 111. Происходит раньше не означает происходит-раньше 2. Из того, что А происходит раньше В не следует, что А происходит-раньше В Поток 2 if (ready) // B print(x); Поток 1 x = 42 ready = true; // A int x; bool ready = false; 111
- 112. Происходит раньше не означает происходит-раньше 2. Из того, что А происходит раньше В не следует, что А происходит-раньше В Поток 2 if (ready) print(x); Поток 1 x = 42 ready = true; int x; bool ready = false; 112 происходит-раньше
- 113. Происходит раньше не означает происходит-раньше 2. Из того, что А происходит раньше В не следует, что А происходит-раньше В Поток 2 if (ready) print(x); Поток 1 x = 42 ready = true; int x; bool ready = false; 113 происходит-раньше
- 114. Отношение happens-before определяет, какие операции видят последствия других операций. Допустим A и В - операции в многопоточной программе. Тогда если А происходит-раньше В, тогда эффект (результат операции, который отразился в памяти) операции А становится видим для потока, выполняющего операцию В. Происходит-раньше ≠ происходит раньше 1. Из того, что А происходит-раньше В не следует, что А происходит раньше В. 2. Из того, что А происходит раньше В не следует, что А происходит-раньше В Отношение происходит-раньше имеет место тогда (и только тогда), когда это определёно стандартом языка. 114
- 115. Виды упорядочивания инструкций в С++ 115
- 116. Последовательная согласованность (sequential consistency) std::atomic<int> x{0}, y{0}, v{0}, w{0} void thread1() { x.store(1, std::memory_order_seq_cst); v.store(y.load(std::memory_order_seq_cst), std::memory_order_seq_cst); } void thread2() { y.store(1, std::memory_order_seq_cst); w.store(x.load(std::memory_order_seq_cst), std::memory_order_seq_cst); } int main() { std::thread t1{thread1}, t2{thread2}; t1.join(); t2.join(); assert(v != 0 || w != 0); assert не сработает 116
- 117. Последовательная согласованность (sequential consistency) std::atomic<int> data{0}; std::atomic<bool> ready{false}; int main() { std::thread producer{[]{ data.store(42, std::memory_order_seq_cst); ready.store(true, std::memory_order_seq_cst); }}; std::thread consumer{[]{ while (!ready.load(std::memory_order_seq_cst)) { } std::cout << data.load(std::memory_order_seq_cst); }}; producer.join(); consumer.join(); 42 117
- 118. Последовательная согласованность (sequential consistency) std::atomic<int> z{0}; std::atomic<bool> x{false}, y{false}; int main(int argc, const char *argv[]) { std::thread store_y{[]{ x.store(true, std::memory_order_seq_cst); }}; std::thread store_x{[]{ y.store(true, std::memory_order_seq_cst); }}; std::thread read_x_then_y{[]{ while (!x.load(std::memory_order_seq_cst)) { } if (y.load(std::memory_order_seq_cst)) z.fetch_add(1, std::memory_order_seq_cst); }}; std::thread read_y_then_x{[]{ while (!y.load(std::memory_order_seq_cst)) { } if (y.load(std::memory_order_seq_cst)) z.fetch_add(1, std::memory_order_seq_cst); }}; store_x.join(); store_y.join(); read_x_then_y.join(); read_y_then_x.join(); std::cout << z.load(std::memory_order_seq_cst); z > 0 118
- 119. Ослабленное упорядочение (relaxed ordering) std::atomic<int> x{0}, y{0}, v{0}, w{0} void thread1() { x.store(1, std::memory_order_relaxed); v.store(y.load(std::memory_order_relaxed), std::memory_order_relaxed); } void thread2() { y.store(1, std::memory_order_relaxed); w.store(x.load(std::memory_order_relaxed), std::memory_order_relaxed); } int main() { std::thread t1{thread1}, t2{thread2}; t1.join(); t2.join(); assert(v != 0 || w != 0); assert может сработать 119
- 120. Ослабленное упорядочение (relaxed ordering) std::atomic<int> data{0}; std::atomic<bool> ready{false}; int main() { std::thread producer{[]{ data.store(42, std::memory_order_relaxed); ready.store(true, std::memory_order_relaxed); }}; std::thread consumer{[]{ while (!ready.load(std::memory_order_relaxed)) { } std::cout << data.load(std::memory_order_relaxed); }}; producer.join(); consumer.join(); 42 не гарантируется 120
- 121. Ослабленное упорядочение (relaxed ordering) std::atomic<int> z{0}; std::atomic<bool> x{false}, y{false}; int main(int argc, const char *argv[]) { std::thread store_y{[]{ x.store(true, std::memory_order_relaxed); }}; std::thread store_x{[]{ y.store(true, std::memory_order_relaxed); }}; std::thread read_x_then_y{[]{ while (!x.load(std::memory_order_relaxed)) { } if (y.load(std::memory_order_relaxed)) z.fetch_add(1, std::memory_order_relaxed); }}; std::thread read_y_then_x{[]{ while (!y.load(std::memory_order_relaxed)) { } if (y.load(std::memory_order_relaxed)) z.fetch_add(1, std::memory_order_relaxed); }}; store_x.join(); store_y.join(); read_x_then_y.join(); read_y_then_x.join(); std::cout << z.load(std::memory_order_relaxed); z >= 0 121
- 122. Метафора человека с блокнотом Иван 34 9 45 -3 21 0 9 7 11 Иван Значение переменной x x.load(memory_order_relaxed) 122
- 123. Метафора человека с блокнотом Иван 34 9 45 -3 21 0 9 7 11 Иван Значение переменной x 123 x.load(memory_order_relaxed)
- 124. Метафора человека с блокнотом Иван 34 9 45 -3 21 0 9 7 11 Иван Значение переменной x 124 x.load(memory_order_relaxed) encore!
- 125. Метафора человека с блокнотом Иван 34 9 45 -3 21 0 9 7 11 Значение переменной x x.load(memory_order_relaxed) Иван 125
- 126. Метафора человека с блокнотом Иван 34 9 45 -3 21 0 9 7 11 -8 Иван Значение переменной x x.store(-8, memory_order_relaxed) 126
- 127. Метафора человека с блокнотом Иван 34 9 45 -3 21 0 9 7 11 -8 Значение переменной x x.load(memory_order_relaxed) Иван 127
- 128. Метафора человека с блокнотом Иван Сергей Анна ... 34 9 45 -3 21 0 9 7 11 -8 Иван Анна Сергей Значение переменной x 128
- 129. Барьеры памяти 129
- 131. Иерархическая структура современных многоядерных систем кэш 2 кэш 1 Память кэш 2 кэш 1 кэш 1 кэш 1 Процессорные ядра 131
- 132. Метафора репозитория 1 кэш L1 2 кэш L1 Память 132
- 133. Метафора репозитория 1 кэш L1 2 кэш L1 Память mov [x], 1 mov r1, [y] mov [y], 1 mov r2, [x] 133
- 135. Метафора репозитория 1 2 Рекс Мухтар Центральный репозиторий Утечка данных из центрального репозитория в локальный и обратно 135
- 136. Метафора репозитория 1 2 Рекс Мухтар Центральный репозиторий mov [x], 1 x = 1 x = 0 Утечка данных из центрального репозитория в локальный и обратно x = 0 136
- 137. Метафора репозитория 1 2 Рекс Мухтар Центральный репозиторий mov [x], 1 x = 1 x = 1 Утечка данных из центрального репозитория в локальный и обратно x = 0 137
- 138. Метафора репозитория 1 2 Рекс Мухтар Центральный репозиторий mov [x], 1 x = 1 x = 1 Утечка данных из центрального репозитория в локальный и обратно x = 1 138
- 139. Метафора репозитория 1 2 Рекс Мухтар Центральный репозиторий mov [x], 1 x = 1 x = ? x = ? Неизвестно, когда изменения распространятся на другие потоки. 139
- 140. Метафора репозитория 1 2 Рекс Мухтар Центральный репозиторий mov [x], 1 mov r1, [y] mov [y], 1 mov r2, [x] x = 0 y = 0 x = 0 y = 0 x = 0 y = 0 140
- 141. Метафора репозитория 1 2 Рекс Мухтар Центральный репозиторий mov [x], 1 mov r1, [y] mov [y], 1 mov r2, [x] x = 0 y = 1 x = 1 y = 0 x = 0 y = 0 141
- 142. Метафора репозитория 1 2 Рекс Мухтар Центральный репозиторий mov [x], 1 mov r1, [y] mov [y], 1 mov r2, [x] x = ? {0,1} y = 1 x = 1 y = ? {0,1} x = ? {0,1} y = ? {0,1} 142
- 144. Барьер LoadLoad 1 Рекс Центральный репозиторий LoadLoad x = 1 y = 0 x = 1 y = 0 git pull, hg pull, svn update, cvs update Барьер LoadLoad: ▪ Предотвращает переупорядочивания между загрузками до барьера и загрузками после барьера. ▪ Гарантирует, что загруженные из центрального репозитория (памяти) в локальный репозиторий (кэш) значения будут по крайней мере такие же новые, как и последнее значение, которое “просочилось” из центрального репозитория. 144
- 145. Барьер LoadLoad 1 Рекс Центральный репозиторий LoadLoad x = 1 y = 0 x = 1 y = 0 git pull, hg pull, svn update, cvs update // Так получилось, что // widget.ready = true утекло // в локальный репозиторий if (widget.ready) { // Подгрузить всё остальное // содержимое widget - // такое же “свежее”, как ready LoadLoadFence(); do_something(widget); } 145
- 146. Барьер StoreStore 1 Рекс Центральный репозиторий StoreStore x = 1 y = 0 Барьер StoreStore: ▪ Предотвращает переупорядочивания между сохранениями до барьера и сохранениями после барьера. ▪ Гарантирует, что загруженные из локального репозитория (кэш) в локальный репозиторий (память) значения будут по крайней мере такие же новые, как и последнее значение, которое “просочилось” из локального репозитория. x = 1 y = 0 git push, hg push, svn commit, cvs commit 146
- 147. Барьер StoreStore 1 Рекс Центральный репозиторий StoreStore x = 1 y = 0 x = 1 y = 0 git push, hg push, svn commit, cvs commit widget.x = x; widget.y = y; StoreStoreFence(); widget.ready = true; // Если ready = true просочится // Мухтару, то он увидит увидит // на центральном репозитории // всё остальные поля widget, // которые для него подготовил Рекс 147
- 148. Барьер LoadStore 1 Рекс mov r1, [y] mov r2, [x] mov [z], 42 mov [w], r3 mov [v], r4 Операции загрузки load Операции сохранения store Переупорядочивание LoadStore 1. Есть набор инструкций, состоящий из операций сохранения и загрузки. 148
- 149. Барьер LoadStore 1 Рекс mov r1, [y] mov r2, [x] mov [z], 42 mov [w], r3 mov [v], r4 Операции загрузки load - отложены Операции сохранения store - выполнены Переупорядочивание LoadStore 1. Есть набор инструкций, состоящий из операций сохранения и загрузки. 2. Если Рекс встречает операцию загрузки, то он просматривает следующие операции сохранения, и если они абсолютно не связаны с текущей операцией загрузки, то он откладывает выполнение операции загрузки и в первую очередь выполняет операции сохранения. 149
- 150. Барьер LoadStore 1 Рекс mov r1, [y] mov r2, [x] mov [z], 42 mov [w], r3 mov [v], r4 Будут промахи по кэшу... Будут попадания в кэш... Переупорядочивание LoadStore 1. Есть набор инструкций, состоящий из операций сохранения и загрузки. 2. Если Рекс встречает операцию загрузки, которые промахиваются по кэшу, то он просматривает следующие операции сохранения, которые попадают в кэш, и если они абсолютно не связаны с текущей операцией загрузки, то он откладывает выполнение операции загрузки и в первую очередь выполняет операции сохранения. 150
- 151. Барьер LoadStore 1 Рекс mov r1, [y] mov r2, [x] LoadStore mov [z], 42 mov [w], r3 mov [v], r4 Будут промахи по кэшу... Будут попадания в кэш... Переупорядочивание LoadStore 1. Есть набор инструкций, состоящий из операций сохранения и загрузки. 2. Если Рекс встречает операцию загрузки, которые промахиваются по кэшу, то он просматривает следующие операции сохранения, которые попадают в кэш, и если они абсолютно не связаны с текущей операцией загрузки, то он откладывает выполнение операции загрузки и в первую очередь выполняет операции сохранения. 151
- 152. Барьер StoreLoad 1 Рекс mov [x], 1 mov r1, [y] 2 Мухтар mov [y], 1 mov r2, [x] x = 1 y = 0 x = 0 y = 1 r1 = 0 r2 = 0 152
- 153. Барьер StoreLoad 1 Рекс mov [x], 1 StoreLoad mov r1, [y] 2 Мухтар mov [y], 1 StoreLoad mov r2, [x] x = 1 y = ? x = ? y = 1 Барьер StoreLoad: ▪ Гарантирует видимость для других процессоров всех операций сохранения, выполненных до барьера. ▪ Обеспечивает для всех операций загрузки, выполненных после барьера, получение результатов, которые имеют место во время барьера. ▪ Барьер предотвращает r1 = r2 = 0 ▪ StoreLoad ≠ StoreStore + LoadLoad 153
- 154. Барьер StoreLoad 1 Рекс mov [x], 1 StoreLoad mov r1, [y] x = 1 y = ? Барьер StoreLoad (≠ StoreStore + LoadLoad): 1. Отправка (push) всех изменений в центральный репозиторий. Центральный репозиторий 154
- 155. Барьер StoreLoad 1 Рекс mov [x], 1 StoreLoad mov r1, [y] x = 1 y = ? Барьер StoreLoad (≠ StoreStore + LoadLoad): 1. Отправка (push) всех изменений в центральный репозиторий. 2. Ожидание завершения выполнения операции отправки (в отличие от StoreStore, который может выполняться с задержкой). Центральный репозиторий 155
- 156. Барьер StoreLoad 1 Рекс mov [x], 1 StoreLoad mov r1, [y] x = 1 y = ? Барьер StoreLoad (≠ StoreStore + LoadLoad): 1. Отправка (push) всех изменений в центральный репозиторий. 2. Ожидание завершения выполнения операции отправки (в отличие от StoreStore, который может выполняться с задержкой). 3. Загрузка (pull) всех последних изменений из центрального репозитория (в отличие от LoadLoad, который не загружает абсолютно последние изменения) Центральный репозиторий 156
- 157. Семантика захват- освобождение (acquire- release semantics) 157
- 158. Семантика захвата (acquire) Семантика захвата и освобождения ▪ Применяется к операциям чтения или чтения- модификации-записи, при этом такая операция становится операцией чтения-захвата (read-acquire). ▪ Предотвращает переупорядочивание инструкции чтения- захвата и всех следующих в программе операций чтения или записи. ▪ Применяется к операциям записи или чтения- модификации-записи, причём такая операция становится операцией записи-освобождения (write-release). ▪ Предотвращает переупорядочивание инструкции записи- освобождения со всеми предшествующими в программе операциями чтения или записи. Семантика освобождения (release) 158
- 159. read-acquire Семантика захвата и освобождения read / write read / write read / write read / write read / write read / write read / write read / write read / write read / write write-release 159
- 160. read-acquire Семантика захвата и освобождения read / write read / write read / write read / write read / write read / write read / write read / write read / write read / write write-release 160
- 161. Захват и освобождение - в терминах барьеров StoreLoadFence StoreStoreFence LoadStoreFenceLoadLoadFence Acquire (захват) Release (освобождение) 161
- 162. LoadLoadFence + LoadStoreFence Захват и освобождение - в терминах барьеров read / write read / write read / write read / write read / write read / write read / write read / write StoreStoreFence + LoadStoreFence read-acquire write-release 162
- 163. read / write read / write read / write read / write read / write read / write read / write read / write LoadLoadFence + LoadStoreFence Захват и освобождение - в терминах барьеров StoreStoreFence + LoadStoreFence read-acquire write-release 163
- 164. LoadLoadFence + LoadStoreFence Захват и освобождение - в терминах барьеров read / write read / write read / write read / write read / write read / write read / write read / write StoreStoreFence + LoadStoreFence read-acquire write-release 164
- 165. LoadLoadFence + LoadStoreFence Захват и освобождение - в терминах барьеров read / write read / write read / write read / write read / write read / write read / write read / write StoreStoreFence + LoadStoreFence read-acquire write-release 1 2 165
- 166. LoadLoadFence + LoadStoreFence Захват и освобождение - в терминах барьеров read / write read / write read / write read / write read / write read / write read / write read / write StoreStoreFence + LoadStoreFence read-acquire write-release 2 1 2 1 166
- 167. LoadLoadFence + LoadStoreFence Захват и освобождение - в терминах барьеров read / write read / write read / write read / write read / write read / write read / write read / write LoadStoreFence + StoreStoreFence read-acquire write-release 167
- 168. Поток 2 ready.load( memory_order_acquire); print(x); Поток 1 x = 42 ready.store(true, memory_order_release); Семантика захват-освобождение на примере с публикацией int x; bool ready = false; 168
- 169. Поток 1 x = 42 ready.store(true, memory_order_release); Семантика захват-освобождение на примере с публикацией Поток 2 ready.load( memory_order_acquire); print(x); int x; bool ready = false; Синхронизируется-с Synchronizes-with Всё, что здесь... … будет видно здесь 169
- 170. Поток 1 x = 42 ready.store(true, memory_order_release); Семантика захват-освобождение на примере с публикацией Поток 2 ready.load( memory_order_acquire); print(x); int x; bool ready = false; Синхронизируется-с Synchronizes-with … будет видно здесь Всё, что здесь... Операция записи- освобождения Операция чтения- захвата 170
- 171. Семантика захват-освобождение на примере с публикацией Поток 1 void initWidget(x, y, z) { w.x = x; w.y = x; w.z = z; ready.store(true, memory_order_release); } Поток 2 void useWidget() { while (!ready.load( memory_order_acquire)) {} doSomething(w); } widget w; bool ready = false; 171
- 172. Поток 2 void useWidget() { while (!ready.load( memory_order_acquire)) {} doSomething(w); } Семантика захват-освобождение на примере с публикацией Поток 1 void initWidget(x, y, z) { w.x = x; w.y = x; w.z = z; ready.store(true, memory_order_release); } widget w; bool ready = false; Синхронизируется-с Synchronizes-with Всё, что здесь... … будет видно здесь Операция записи- освобождения Операция чтения-захвата 172
- 173. Поток 2 void useWidget() { while (!ready.load( memory_order_acquire)) {} s1 = to_string(w); s2 = "number " + s1; print(s2); } Семантика захват-освобождение на примере с публикацией int x, y, z; bool ready = false; Поток 1 void initWidget(x, y, z) { x = 10 y = x + 20; z = x + 12; ready.store(true, memory_order_release); } Синхронизируется-с Synchronizes-with 173
- 174. Поток 2 void useWidget() { while (!ready.load( memory_order_acquire)) {} s1 = to_string(w); s2 = "number " + s1; print(s2); } Семантика захват-освобождение на примере с публикацией int x, y, z; bool ready = false; Поток 1 void initWidget(x, y, z) { x = 10 y = x + 20; z = x + 12; ready.store(true, memory_order_release); } Синхронизируется-с Synchronizes-with Операция записи- освобождения Операция чтения-захвата 174
- 175. Захват и освобождение в С++ std::memory_order_acquire ▪ Применяется к операциям чтения или чтения- модификации-записи: load, compare_exchange, fetch_add, fetch_or, etc. ▫ x.load(std::memory_order_acquire); ▫ compare_exchange_weak(x, y, std::memory_order_acquire); ▪ Применяется к операциям записи или чтения- модификации-записи: store, operator=, load, compare_exchange, fetch_add, fetch_or, etc ▫ x.store(42, std::memory_order_release); ▫ compare_exchange_weak(x, y, std::memory_order_release); std::memory_order_release 175
- 177. Отношение synchronized-with (синхронизируется-с) Отношение syncrhonized-with более сильное по сравнению с happens- before, т.е.: synchronizes-with ⟶ happens-before 177
- 178. Отношение synchronized-with (синхронизируется-с) Отношение syncrhonized-with более сильное по сравнению с happens- before, т.е.: synchronizes-with ⟶ happens-before Операция записи A над переменной x синхронизируется-с такой операцией операцией чтения B над x, которая читает значение, сохранённое 1. или операцией A. 2. или следующей за A операцией записи над x в том же потоке, который выполнил A. 3. или последовательностью операций чтения-модификации-записи над x в любом потоке, при условии, что значение, прочитанное первым потоком в этой последовательности, является значением, записанным операцией A. 178
- 179. Отношение synchronized-with (синхронизируется-с) Отношение syncrhonized-with более сильное по сравнению с happens- before, т.е.: synchronizes-with ⟶ happens-before Операция записи A над переменной x синхронизируется-с такой операцией операцией чтения B над x, которая читает значение, сохранённое 1. или операцией A. 2. или следующей за A операцией записи над x в том же потоке, который выполнил A. 3. или последовательностью операций чтения-модификации-записи над x в любом потоке, при условии, что значение, прочитанное первым потоком в этой последовательности, является значением, записанным операцией A. 179
- 180. Отношение synchronized-with (синхронизируется-с) Отношение syncrhonized-with более сильное по сравнению с happens- before, т.е.: synchronizes-with ⟶ happens-before Операция записи A над переменной x синхронизируется-с такой операцией операцией чтения B над x, которая читает значение, сохранённое 1. или операцией A. 2. или следующей за A операцией записи над x в том же потоке, который выполнил A. 3. или последовательностью операций чтения-модификации-записи над x в любом потоке, при условии, что значение, прочитанное первым потоком в этой последовательности, является значением, записанным операцией A. Иначе: Если поток 1 сохраняет значение, а поток 2 читает это значение, то существует отношение синхронизируется-с между операциями сохранения и загрузки. 180
- 181. Поток 1 void prepare() { w.x = x; w.y = x; cntr++; w.ready.store(true, memory_order_release); } Операци Acquire-release (synchronized-with) в С++ Поток 2 void utilize() { while (!w.ready.load( memory_order_acquire)) {} doSomethingWith(w); writeLog(cntr); } Widget w; int cntr; Синхронизируется-с Synchronizes-with 181
- 182. Поток 1 void prepare(Widget &w) { w.x = x; w.y = x; cntr++; w.ready.store(true, memory_order_release); } Операци Acquire-release (synchronized-with) в С++ Поток 2 void utilize() { if (!w.ready.load( memory_order_acquire)){ doSomethingWith(w); writeLog(cntr); } Widget w; int cntr; Синхронизируется-с Synchronizes-with 182
- 183. Поток 2 void utilize() { bool ready = w.ready.load( memory_order_relaxed); if (ready) { atomic_thread_fence( memory_order_acquire)){ doSomethingWith(w); writeLog(cntr); } Поток 1 void prepare(Widget &w) { w.x = x; w.y = x; cntr++; atomic_thread_fence(, memory_order_release); w.ready.store(true, memory_order_relaxed); } Барьеры acquire-release (synchronized-with) в С++ Widget w; int cntr; 183
- 184. Барьеры acquire-release (synchronized-with) в С++ Рекс Мухтар Центральный репозиторий (ЦР) 184
- 185. Барьеры acquire-release (synchronized-with) в С++ Рекс Мухтар Центральный репозиторий (ЦР) Запись в w, cntr 1 185
- 186. Барьеры acquire-release (synchronized-with) в С++ Рекс Мухтар Центральный репозиторий (ЦР) Барьер release - все данные загружаются в “репозиторий” Запись в w и cntr 1 2 186
- 187. Барьеры acquire-release (synchronized-with) в С++ Рекс Мухтар Центральный репозиторий (ЦР) Барьер release - все данные загружаются в “репозиторий” Запись в w и cntr 1 2 Запись true в ready 3 187
- 188. Барьеры acquire-release (synchronized-with) в С++ Рекс Барьер release - все данные загружаются в “репозиторий” Мухтар Центральный репозиторий (ЦР) Запись в w и cntr 1 ready просачивается в “репозиторий” 2 Запись true в ready 3 4 188
- 189. Барьеры acquire-release (synchronized-with) в С++ Рекс Мухтар Центральный репозиторий (ЦР) Запись в w и cntr ready просачивается в “репозиторий” ready просачивается из ЦР Мухтару 1 Барьер release - все данные загружаются в “репозиторий” 2 Запись true в ready 3 4 5 189
- 190. Барьеры acquire-release (synchronized-with) в С++ Рекс Мухтар Центральный репозиторий (ЦР) Запись в w и cntr 1 Барьер release - все данные загружаются в “репозиторий” 2 Запись true в ready 3 ready просачивается из ЦР Мухтару Чтение true в ready ready просачивается в “репозиторий” 4 56 190
- 191. Барьеры acquire-release (synchronized-with) в С++ Рекс Мухтар Центральный репозиторий (ЦР) Барьер release - все данные загружаются в “репозиторий” Запись в w и cntr 1 2 ready просачивается в “репозиторий” ready просачивается из ЦР Мухтару Барьер acquire - данные загружаются из ЦР Мухатору Запись true в ready 3 4 5 7 Чтение true в ready 6 191
- 192. Барьеры acquire-release (synchronized-with) в С++ Рекс Мухтар Центральный репозиторий (ЦР) Запись в w и cntr Барьер release - все данные загружаются в “репозиторий” ready просачивается в “репозиторий” 1 2 Запись true в ready 3 4 ready просачивается из ЦР Мухтару 5 Чтение true в ready Барьер acquire - данные загружаются из ЦР Мухатору 7 Чтение w и cntr 6 8 192
- 193. std::vector<int> queue; std::atomic<int> count; void pop() { for (auto i = 0; i < num_of_items; i++) queue.push(i); count.store(num_of_items, std::memory_order_release); } void consume() { for (;;) { auto item_index = count.fetch_sub(1, ?); if (item_index <= 0) { wait_for_items(); continue; } process(queue[item_index]); } } Последовательность освобождений 193
- 194. Операция записи A над переменной x синхронизируется-с такой операцией операцией чтения B над x, которая читает значение, сохранённое 1. или операцией A. 2. или следующей за A операцией записи над x в том же потоке, который выполнил A. 3. или последовательностью операций чтения-модификации-записи над x в любом потоке, при условии, что значение, прочитанное первым потоком в этой последовательности, является значением, записанным операцией A. Отношение synchronized-with (синхронизируется-с) 194
- 195. Операция записи A над переменной x синхронизируется-с такой операцией операцией чтения B над x, которая читает значение, сохранённое 1. или операцией A. 2. или следующей за A операцией записи над x в том же потоке, который выполнил A. 3. или последовательностью операций чтения-модификации-записи над x в любом потоке, при условии, что значение, прочитанное первым потоком в этой последовательности, является значением, записанным операцией A. Отношение synchronized-with (синхронизируется-с) 195 Если существует последовательность операций чтения-модификации- записи, помеченных признаком acquire, причём каждая операция загрузки загружает значение, записанное предыдущей операцией, то такая цепочка называется последовательностью освобождений. Операция чтения может быть помечена любым признаком.
- 196. std::vector<int> queue; std::atomic<int> count; void pop() { for (auto i = 0; i < num_of_items; i++) queue.push(i); count.store(num_of_items, std::memory_order_release); } void consume() { for (;;) { auto item_index = count.fetch_sub(1, std::memory_order_acquire); if (item_index <= 0) { wait_for_items(); continue; } process(queue[item_index]); } } Последовательность освобождений 196
- 197. Последовательность освобождений 197 pop() { for (...) { queue.push (...) } count.store( release) consume() { ... count.fetch_sub( acquire) process(...) consume() { ... count.fetch_sub( acquire) process(...) T1 T2 T3 10 9 8 синхронизируется-с цепочка зависимостей происходит раньше
- 198. Связь семантики захвата-освобождения с проблемой взаимного исключения или что же такое мьютекс? 198
- 199. class spinlock_mutex { std::atomic_flag flag; public: spinlock_mutex(): flag{ATOMIC_FLAG_INIT} { } void lock() { while (flag.test_and_set( std::memory_order_acquire)); } void unlock() { flag.clear(std::memory_order_release); } }; Реализация спинлока на основе атомарного флага 199
- 200. class spinlock_mutex { std::atomic_flag flag; public: spinlock_mutex(): flag{ATOMIC_FLAG_INIT} { } void lock() { while (flag.test_and_set( std::memory_order_acquire)); } void unlock() { flag.clear(std::memory_order_release); } }; Реализация спинлока на основе атомарного флага Операция записи-освобождения Операция чтения-захвата 200
- 201. ... mut.lock(); // A y = 2; // B mut.unlock(); ... Мьютекс и семантика захвата-освобождения Что всё-таки подразумевается под переупорядочиванием инструкций (A и В) в потоке? T1 Это означает, что есть какой-то второй поток, который “видит” эти операции, выполняющиеся в другом порядке. 201
- 202. ... mut.lock(); y = 2; mut.unlock(); ... Мьютекс и семантика захвата-освобождения Что всё-таки подразумевается под переупорядочиванием инструкций (A и В) в потоке? T1 T2 2 1 Это означает, что есть какой-то второй поток, который “видит” эти операции, выполняющиеся в другом порядке. 202
- 203. Мьютекс и семантика захвата-освобождения Что всё-таки подразумевается под переупорядочиванием инструкций (A и В) в потоке? T1 Это означает, что есть какой-то второй поток, который “видит” эти операции, выполняющиеся в другом порядке. T2 ... mut.lock(); y *= 10; mut.unlock(); ... ... mut.lock(); y = 2; mut.unlock(); ... 203
- 204. Мьютекс и семантика захвата-освобождения Что всё-таки подразумевается под переупорядочиванием инструкций (A и В) в потоке? Это означает, что есть какой-то второй поток, который “видит” эти операции, выполняющиеся в другом порядке. ... mut.lock(); mut.unlock(); y = 2; ... T1 T2 ... mut.lock(); y *= 10; mut.unlock(); ... гонка! 204
- 205. x = 1; mut.lock(); y = 2; mut.unlock(); z = 3; Мьютекс и семантика захвата-освобождения mut.lock(); x = 1; y = 2; z = 3; mut.unlock(); Можно трансформировать это в это? 205
- 206. x = 1; mut.lock(); y = 2; mut.unlock(); z = 3; Мьютекс и семантика захвата-освобождения mut.lock(); x = 1; y = 2; z = 3; mut.unlock(); Можно трансформировать это в это? mut.lock(); x = 1; y = 2; z = 3; mut.unlock(); x = 1; mut.lock(); y = 2; mut.unlock(); z = 3; в это?а это 206
- 207. x = 1; mut.lock(); y = 2; mut.unlock(); z = 3; Мьютекс и семантика захвата-освобождения mut.lock(); x = 1; y = 2; z = 3; mut.unlock(); Можно трансформировать это в это? mut.lock(); x = 1; y = 2; z = 3; mut.unlock(); x = 1; // гонка! mut.lock(); y = 2; mut.unlock(); z = 3; // гонка! в это?а это 207
- 208. ... void lock() { while (flag.test_and_set( std::memory_order_relaxed)); } void unlock() { flag.clear(std::memory_order_relaxed); } Мьютекс и семантика захвата-освобождения Допустим 208
- 209. ... void lock() { while (flag.test_and_set( std::memory_order_relaxed)); } void unlock() { flag.clear(std::memory_order_relaxed); } mut.lock(); x = 1; y = 2; z = 3; mut.unlock(); Мьютекс и семантика захвата-освобождения Допустим Но тогда x = 1; mut.lock(); y = 2; mut.unlock(); z = 3; 209
- 210. ... void lock() { while (flag.test_and_set( std::memory_order_relaxed)); } void unlock() { flag.clear(std::memory_order_relaxed); } Но тогда mut.lock(); x = 1; y = 2; z = 3; mut.unlock(); Мьютекс и семантика захвата-освобождения x = 1; mut.lock(); y = 2; mut.unlock(); z = 3; Допустим 210
- 211. Мьютекс и семантика захвата-освобождения k = 1; l = 2; mut.lock(); x = 3; y = 4; z = 5; mut.unlock(); p = 6; q = 7; 211
- 212. Мьютекс и семантика захвата-освобождения k = 1; l = 2; mut.lock(); x = 3; y = 4; z = 5; mut.unlock(); p = 6; q = 7; flag.clear(std:: memory_order_release) flag.test_and_set( std:: memory_order_acquire) 212
- 213. acquire release Мьютекс и семантика захвата-освобождения k = 1; l = 2; mut.lock(); x = 3; y = 4; z = 5; mut.unlock(); p = 6; q = 7; Мьютекс определяет семантику захвата-освобождения (lock - запись-освобождение, release - чтение-захват): mutex ⟶ acquire-release flag.clear(std:: memory_order_release) flag.test_and_set( std:: memory_order_acquire) 213
- 214. acquire release Мьютекс и семантика захвата-освобождения k = 1; l = 2; mut.lock(); x = 3; y = 4; z = 5; mut.unlock(); p = 6; q = 7; Мьютекс определяет семантику захвата-освобождения (lock - запись-освобождение, release - чтение-захват): mutex ⟶ acquire-release Является ли пара операций захвата-освобождения достаточной для реализации взаимного исключения acquire-release ⟶ mutex ?? flag.clear(std:: memory_order_release) flag.test_and_set( std:: memory_order_acquire) 214
- 215. ... mut.lock(); y = 2; mut.unlock(); ... Мьютекс и семантика захвата-освобождения ... mut.lock(); y *= 10; mut.unlock(); ... ... mut.lock(); y += 22; mut.unlock(); ... T1 T2 T3 215
- 216. flag.load() // 0 ... y = 2; ... flag.store(0) ... Мьютекс и семантика захвата-освобождения flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 0 ... y += 22; ... flag.store(0) flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 0 ... y *= 10; ... flag.store(0); T1 T3T2 216
- 217. Мьютекс и семантика захвата-освобождения T1 T3T2 load-acquire ... y = 2; ... store-release ... flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 load-acquire ... y += 22; ... store-release flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 flag.load() // 1 load-acquire ... y *= 10; ... store-release 217 Synchronizes-with Синхронизируется-с Synchronizes-with Синхронизируется-с
- 218. Мьютекс и семантика захвата-освобождения T1 T3T2 load-acquire ... y += 22; ... store-release load-acquire ... y *= 10; ... store-release Synchronizes-with Синхронизируется-с Synchronizes-with Синхронизируется-с 218 load-acquire ... y = 2; ... store-release ...
- 219. Мьютекс и семантика захвата-освобождения T1 T3T2 load-acquire ... y = 2; ... store-release ... load-acquire ... y += 22; ... store-release load-acquire ... y *= 10; ... store-release Synchronizes-with Синхронизируется-с Synchronizes-with Синхронизируется-с 219 Пара загрузки-сохранения (load-store) обеспечивает взаимное исключение в том и только в том случае, если загрузка является операцией захвата (acquire), а сохранение - операцией освобождения (release), и если операция загрузки синхронизируется-с (synchronized-with) операцией сохранения предыдущей пары загрузки-сохранения, а операция сохранения синхронизируется с операцией сохранения последующей пары загрузки сохранения.
- 220. Решение проблемый двойной проверки с помощью модели памяти С++ 220
- 221. Проблема двойной проверки 221 Widget* Widget::instance_ptr{nullptr}; Widget* Widget::instance() { if (instance_ptr == nullptr) { // 1: 1 проверка lock_guard<mutex> lock{mut}; // 2: запираем if (instance_ptr == nullptr) { // 3: 2 проверка instance_ptr = new Widget(); // 4: создать // и присвоить } } // 5: отпираем return instance_ptr; // 6: возвращаем } Основная проблема: гонка данных между операциями 1 и 4. Она может привести, например, к частичной инициализации instance_ptr
- 222. Проблема двойной проверки 222 std::atomic<Widget*> Widget::instance_ptr{nullptr}; Widget* Widget::instance() { if (instance_ptr == nullptr) { // 1: 1 проверка lock_guard<mutex> lock{mut}; // 2: запираем if (instance_ptr == nullptr) { // 3: 2 проверка instance_ptr = new Widget(); // 4: создать // и присвоить } } // 5: отпираем return instance_ptr; // 6: возвращаем }
- 223. Проблема двойной проверки 223 std::atomic<Widget*> Widget::instance_ptr{nullptr}; Widget* Widget::instance() { if (instance_ptr == nullptr) { lock_guard<mutex> lock{mut}; if (instance_ptr == nullptr) { instance_ptr = new Widget(); } } return instance_ptr; } нужен барьер нужен барьер
- 224. Проблема двойной проверки в С++ 224 std::atomic<Widget*> Widget::instance_ptr{nullptr}; Widget* Widget::instance() { Widget* tmp = instance_ptr.load(memory_order_relaxed); atomic_thread_fence(memory_order_acquire); if (tmp == nullptr) { lock_guard<mutex> lock{mut}; tmp = instance_ptr.load(memory_order_relaxed); if (tmp == nullptr) { instance_ptr = new Widget(); atomic_thread_fence(memory_order_release); instance_ptr.store(tmp, memory_order_relaxed); } } return tmp; }
- 225. Проблема двойной проверки в С++ 225 std::atomic<Widget*> Widget::instance_ptr{nullptr}; Widget* Widget::instance() { if (instance_ptr.load(memory_order_acquire) == nullptr) { lock_guard<mutex> lock{mut}; tmp = instance_ptr.load(memory_order_relaxed); if (tmp == nullptr) { instance_ptr = new Widget(); instance_ptr.store(tmp, memory_order_release); } } return tmp; }
- 226. instance_ptr = new Widget(); instance_ptr.store(tmp, memory_order_release); } Мьютекс и семантика захвата-освобождения if (instance_ptr.load( memory_order_acquire) == nullptr) { lock_guard<mutex> lock{mut}; tmp = instance_ptr.load( memory_order_relaxed); if (tmp == nullptr) { T1 T2 226 всё здесь видно здесь Synchronizes-with Синхронизируется-с