Переупорядочивание операций процессором

@ReYalp · Регистрация: 27.12.2017

Студворк — интернет-сервис помощи студентам

Разве в многопоточной программе причиной видимости потоками разных состояний разных переменных является переупорядочивание процессором?(Если компилятор не применяет оптимизаций)?
К примеру почему может НЕ упасть(ассерт сработает) следующий код?

C++
1
2
3
4
5
6
7
8
9
10
11
12
bool x = true;
bool y = true;
 
void first(){ //CPU 0
x = false;
assert(y);
}
 
void second(){ //CPU 1
y = false;
assert(x);
}

Разве причина в переупорядочивании операций, а не в протоколе когерентности кешей?

@ReYalp · 13.04.2021, 23:34 **[ТС]**

hoggy,

Сообщение от hoggy

начнется только и только после того, как побочный эффект выражения:

это для одного потока, или такая же последовательность будет видна всем?

@zayats80888 · 13.04.2021, 23:34

Сообщение от ReYalp

тоесть барьер работает и как инструкция не переупорядочивать операции и как инструкция синхронизации кешей(к примеру ожидания всех store из store buffer)

В целом да, но и барьеры бываю разные, зависит от семантихи захвата/освобождения конкретного процессора. ARM'ки, например умеют писать мимо store bufffer, а так же могут ждать, пока он "сфлашится".

@ReYalp · 13.04.2021, 23:41 **[ТС]**

zayats80888, тоесть к примеру если взять самую "простую" архитектуру, тогда барьер release в теории должен дождаться всех операций из store buffer(ну либо пометить их , чтобы операции записи не прошли мимо них) и дождаться всех чтений(вот тут я не особо знаю как работают чтения, в тех примерах которые я читал Memory Barriers: a Hardware View for Software Hackers была invalidation queue, но я знаю что её по факту нет)

@hoggy · 13.04.2021, 23:42

Сообщение от ReYalp

это для одного потока, или такая же последовательность будет видна всем?

безотносительно к потокам.

@ReYalp · 13.04.2021, 23:52 **[ТС]**

hoggy, ничего не понял,какой тогда смысл в такой гарантии если она не гарантирует это для потоков?

@zayats80888 · 13.04.2021, 23:56

Сообщение от ReYalp

вот тут я не особо знаю как работают чтения

Я тоже глубоко не вникал. В с++ есть абстракция над всем этим и четкие правила(безотносительно архитектуры). И в них разобраться гораздо проще, чем в тонкостях архитектуры процессоров, тем более что многие такие детали "защищены политикой безопасности компаний" и не доступны простым смертным, можно лишь публичные "математические" модели изучать.

@ReYalp · 13.04.2021, 23:59 **[ТС]**

zayats80888, но в С++ подобные абстракции только создают отношения "синхронизируется с" и "происходит до", по сути ничего больше , с того что я понял, поправьте если не так

@zayats80888 · 14.04.2021, 00:06

Сообщение от ReYalp

по сути ничего больше

А что вам нужно в высокоуровневом коде?

@ReYalp · 14.04.2021, 00:16 **[ТС]**

zayats80888, мне - ещё не знаю ТК я не до конца разобрался с этим,на данный момент я хочу понять как работают разные барьеры в С++ по отношению к примитивной архитектуре,не более

@zayats80888 · 14.04.2021, 00:21

Не по теме:

Сообщение от ReYalp

на данный момент я хочу понять как работают разные барьеры в С++ по отношению к примитивной архитектуре

Но в вашем примере нет никаких барьеров, так что они никак не работают :)

@ReYalp · 14.04.2021, 08:11 **[ТС]**

zayats80888, это само собой)
а в этом примере?

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
#include <atomic>
#include <thread>
#include <assert.h>
 
bool x = false;
std::atomic<bool> y;
std::atomic<int> z;
 
void write_x_then_y(){
  x = true;
  std::atomic_thread_fence(std::memory_order::memory_order_release);
  y.store(true, std::memory_order_relaxed);
}
 
void read_y_then_x(){
  while(!y.load(std::memory_order_relaxed));
  std::atomic_thread_fence(std::memory_order_acquire);
  if(x)
    ++z;
}
 
 
int main(){
  x = false;
  y = false;
  z = 0;
  std::thread a(write_x_then_y);
  std::thread b(read_y_then_x);
  a.join();
  b.join();
  assert(z.load() != 0);
  return 0;
}

с того что я понгял между барьерами появляется отношение "синхронизируется с" и инкрементация всегда сработает тк запись в x "просихоит до" записи в y. А что здесь происходит с точки зрения архитектуры(любой где есть буфер записи и что-то типа read queue, invalidation queue etc...)?

@zayats80888 · 14.04.2021, 09:16

Сообщение от ReYalp

А что здесь происходит с точки зрения архитектуры(любой где есть буфер записи и что-то типа read queue, invalidation queue etc...)?

По вашей же ссылке из поста №23 буквально этот пример разбирается во второй половине 4.3 с оглядкой на 5.

@ReYalp · 14.04.2021, 09:20 **[ТС]**

zayats80888, действительно так и есть,но барьеры там - это линуксовые барьеры, а у меня в примере барьеры С++.

@ReYalp · 15.04.2021, 13:59 **[ТС]**

zayats80888, можете пожалуйста объяснить как инструкция может выполниться раньше другой, если не считать перестановку компилятором?
Вот есть у меня спинлок, его lock() это acquire, unlock() это release, acquire как бы обозначает что все операции чтения до барьера закончаться ДО любых операций после барьера, тоесть как бы не дает операциям после барьера "пролезть" перед ним, так вопрос следующий :
Как операции вообще могут случиться перед барьером? Если есть

C++
1
2
3
4
read(x);
test();
read(y);
write(z);

процессор же не может как-то выполнить read(y) до test()? read(x) после - возможно при определенных условиях, а вот то что идет после - как и почему?

@zayats80888 · 15.04.2021, 15:04

Сообщение от ReYalp

как инструкция может выполниться раньше другой, если не считать перестановку компилятором?

https://en.wikipedia.org/wiki/Tomasulo_algorithm, например.
В сети полно объяснений и примеров, как камни извлекают и выполняют инструкции.

Сообщение от ReYalp

процессор же не может как-то выполнить read(y) до test()?

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

@ReYalp · 15.04.2021, 15:16 **[ТС]**

zayats80888, еще такой вопрос:
1. Мне понятно как работает "synchronizes with" в случае с release-acquire записью-считыванием, к примеру

C++
1
2
3
4
5
6
7
//thread 1
stores
atomic a = 5 release;
 
//thread 2
if(atomic a == 5 acquire)
loads

Здесь все stores будут выполнены до loads, это понятно.
А что если acquire-release?
к примеру

C++
1
2
3
4
5
6
7
8
9
//thread1
stores
read(atomic a acquire)
ops1
 
//thread2
loads
store(atomic a release)
ops2

если второй поток делает запись после чтения в первом потоке то stores из первого не должны happen before ops2 тк acquire ждет пока закончатся только load-операции, не store, верно?

@zayats80888 · 15.04.2021, 15:34

Сообщение от ReYalp

если второй поток делает запись после чтения в первом потоке

Что значит "после"? Каким соотношением это определить?

Сообщение от ReYalp

тк acquire ждет пока закончатся только load-операции, не store, верно?

Почему ждёт? Просто представь, что данные между потоками пересылаются пакетами. Release - это завершающая операция записи(заголовок пакета, можно отправлять), а acquire - это чтение заголовка пакета(если прочитали, можно читать данные пакета).

@ReYalp · 15.04.2021, 16:00 **[ТС]**

zayats80888,

Сообщение от zayats80888

Что значит "после"? Каким соотношением это определить?

никаким , получается операции acquire-release нельзя синхронизировать?

@zayats80888 · 15.04.2021, 16:09

Сообщение от ReYalp

никаким , получается операции acquire-release нельзя синхронизировать?

Ну а как это сделать? Ты должен acquire прочитать значение, записанное release... Ну и если A случилось раньше C и B случилось раньше C, то это не упорядочивает A и B между собой.

@ReYalp · 15.04.2021, 16:12 **[ТС]**

zayats80888,

Сообщение от zayats80888

Ну а как это сделать? Ну и если A случилось раньше C и B случилось раньше C, то это не упорядочивает A и B между собой.

согласен, но как тогда работает мьютекс если для lock у него используется acquire, а для unlock release? Для чего это?
mutex ac-rel

Новые блоги и статьи Все статьи Все блоги /
Сезонность и суточность закисления почв anaschu 04.07.2026 200 часов это все равно моловато. Есть ситуации, но нестандартные, когда смена происходит за 5 лет. Но обычно это 50 лет и более. Наверное, закисление почвы происходит сезонно в средней. . .	В чем ценность человеческого опыта в глобальном смысле? kumehtar 03.07.2026 Возможно, ценность человека не в том, что он однажды достигает мудрости, а в том, что он становится носителем карты пути. Он знает не только истину, но и последовательность внутренних изменений,. . .	интеграция AnyLogic с самописным REST API и переход на Odoo anaschu 03.07.2026 Успешная интеграция AnyLogic с самописным REST API и переход на промышленную Odoo WMS Сегодня проделал огромный путь от простой симуляции физических процессов до построения полноценной. . .	Поиск всех путей на ориентированном графе. Linux dcc0 02.07.2026 Переработка старого кода из моей статьи. Через несколько переработок от PHP кода к C89 (надеюсь, 89). Но довольно запутанно получилось. Код для Linux. Но если убрать time и то, что с ним. . .
Сам себя обучал rest api anaschu 02.07.2026 Педагогический лайфхак: Почему чистый REST API для ученика намного круче, чем готовые библиотеки Когда мы отказались от капризного JAR-файла AnyLogic и переписали код на стандартный HttpClient,. . .	rest api anylogic - выполнение модели на своём русском сайте anaschu 02.07.2026 Как подружиться с AnyLogic Cloud API, победить провайдеров и развернуться Java-бэкенд в Docker на бесплатном хостинге: Двухдневный лог борьбы Всем привет! Хочу поделиться свежим (и довольно. . .	Где деньги лежат kumehtar 02.07.2026 Это - японская подводная лодка I-52 (тип C2, кодовое имя Momi) вышла из Японии в марте 1944 года с миссией в оккупированную немцами Францию (Лорьян). Это была одна из «Янаги»-миссий по обмену. . .	Krabik для WoW 3.3.5a, многоязычный AmbA 02.07.2026 Допилил бота, думаю что окончательно. Изменения: - добавлена многоязычность - добавлено снятие скриншотов - добавлено поддержание бафов хождения по воде (для жреца, дк и шамана) - и так, по. . .

@ReYalp 63 / 46 / 11 Регистрация: 27.12.2017 Сообщений: 1,484
	13.04.2021, 23:41 [ТС]
	zayats80888, тоесть к примеру если взять самую "простую" архитектуру, тогда барьер release в теории должен дождаться всех операций из store buffer(ну либо пометить их , чтобы операции записи не прошли мимо них) и дождаться всех чтений(вот тут я не особо знаю как работают чтения, в тех примерах которые я читал Memory Barriers: a Hardware View for Software Hackers была invalidation queue, но я знаю что её по факту нет) 0

@ReYalp 63 / 46 / 11 Регистрация: 27.12.2017 Сообщений: 1,484
	13.04.2021, 23:52 [ТС]
	hoggy, ничего не понял,какой тогда смысл в такой гарантии если она не гарантирует это для потоков? 0

@ReYalp 63 / 46 / 11 Регистрация: 27.12.2017 Сообщений: 1,484
	13.04.2021, 23:59 [ТС]
	zayats80888, но в С++ подобные абстракции только создают отношения "синхронизируется с" и "происходит до", по сути ничего больше , с того что я понял, поправьте если не так 0

@ReYalp 63 / 46 / 11 Регистрация: 27.12.2017 Сообщений: 1,484
	14.04.2021, 00:16 [ТС]
	zayats80888, мне - ещё не знаю ТК я не до конца разобрался с этим,на данный момент я хочу понять как работают разные барьеры в С++ по отношению к примитивной архитектуре,не более 0

@ReYalp 63 / 46 / 11 Регистрация: 27.12.2017 Сообщений: 1,484
	14.04.2021, 09:20 [ТС]
	zayats80888, действительно так и есть,но барьеры там - это линуксовые барьеры, а у меня в примере барьеры С++. 0