Что происходит с хранилищем, «проигравшим гонку» за разделяемую память в модели памяти x86 TSO?

Связанный: Инструкции по загрузке Globally Invisible обсуждают странные эффекты, возникающие при пересылке в магазин. Ядро видит свои собственные хранилища до того, как они станут глобально видимыми; пока сохранение все еще находится в буфере хранилища, это последнее сохранение в этом месте из PoV этого ядра. Как только он в конечном итоге фиксируется (после получения эксклюзивного права владения строкой кэша через MESI «чтение для владения»), он становится частью глобального общего порядка хранилищ, поскольку кэши являются согласованными.

@PeterCordes Я не понимаю. Если X=2 из буфера P2 записывается в разделяемую память раньше X=1 (хранится в буфере P1), что увидит P1 при чтении X (1 из своего буфера или 2 из общей памяти)? Кроме того, что происходит с X=1 в буфере P1, когда X=2 записывается в общую память?

Загрузки из P1, которые находятся в программном порядке до сохранения P1, будут видеть X=2 (или какое-то более раннее значение, если они читают кэш еще до фиксации хранилища P2). Загрузки из P1, находящиеся в программном порядке после сохранения, будут видеть X=1. Это остается верным даже после того, как это хранилище фиксирует данные в кеше, а P1 считывает их из кеша вместо пересылки в хранилище. т. е. хранилище P1 идет после хранилища P2 в порядке модификации для этого местоположения (терминология C/C++), с точки зрения всех ядер, включая P1.

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

См. также Может ли x86 переупорядочить узкий магазин с более широкой загрузкой, которая полностью его вместит? для непростого, но показательного случая. Но только для тех основ, о которых вы спрашиваете, только с одним местоположением, которые применимы практически к любому процессору, использующему когерентность кэша MESI, даже при расслабленном порядке памяти, таком как ARMv8.

@PeterCordes Спасибо, чувак! У меня один вопрос "вырванный из контекста". Поскольку я хочу изучить все эти вещи подробно, знаете ли вы какую-нибудь хорошую книгу, которую вы могли бы порекомендовать? Я думал о «Базовом руководстве по согласованности памяти и согласованности кэша», но я не уверен, поскольку в нем не упоминаются термины, которые вы использовали («переупорядочение StoreLoad», «перенаправление хранилища»). Заранее спасибо!

Отличной отправной точкой для переупорядочения памяти и таких терминов, как переупорядочение StoreLoad, являются preshing.com/20120710/… и preshing.com/20120913/acquire-and-release-semantics . Статья в Википедии MESI в порядке, но описание с точки зрения отслеживания общей шины вводит в заблуждение по сравнению с тем, что на самом деле делают современные процессоры («каталог» отслеживает, какая строка находится, чтобы знать, куда отправлять недействительные сообщения / RFO). Я узнал об этом не из книги, поэтому ИДК, хотя это хороший комп. арх. текст является хорошим фоном.

@PeterCordes И еще один вопрос. Это «официальный документ x86-TSO» cl.cam.ac.uk/~pes20/weakmemory/cacm.pdf ? Я также нашел это ( cl.cam.ac.uk/~pes20/weakmemory/x86tso-paper.tphols.pdf), но, как я вижу, это всего лишь предложение (которое принято) и первая статья/ссылка это тот, который мне следует посмотреть/изучить (кстати, обе статьи написали одни и те же люди из Кембриджа).

Это формальное определение модели памяти совсем непросто понять. Это не очень хорошая отправная точка. Хотя, если еще раз просмотреть статью, можно увидеть немало текста, обсуждающего ее, так что, возможно, не так уж и плохо. Неформальное понимание основ того, как все работает, очень полезно для того, чтобы попытаться выяснить, что именно пытается определить формализм. Такие вещи, как документация по модели памяти ядра Linux, могут оказаться полезными (хотя переупорядочение во время компиляции является здесь серьезной проблемой, например, lwn.net/Articles/793253, в отличие от написания на asm и размышлений о процессорах).

Wiki тега x86 ссылки cl.cam.ac.uk/~pes20/weakmemory/x86tso-paper.pdf, «расширенная версия» этой статьи, 2009 года. Кажется, я видел что-то о обновленную версию этой статьи за последние пару лет, но сейчас я не могу ее найти. Давненько я на это не смотрел; Мне было достаточно понять это как программный порядок плюс буфер хранилища с переадресацией хранилища. (Наряду с тем, что IRIW невозможен, так как нет побочного канала, по которому некоторые ядра могли бы видеть хранилища других раньше других, как в POWER)

Во время поиска я нашел Research.swtch.com/hwmm , обзор x86-TSO в сравнении с более расслабленными моделями памяти (например, ARM). Re: IRIW, Будут ли две атомарные записи в разные места в разных потоках всегда отображаться в одном и том же порядке другими потоками? объясняет аппаратный механизм в POWER