Синхронизация кешей процессоров

[Dmitriy40]

Pavia в сообщении #1335472 писал(а):

Dmitriy40 писал о том что на низком уровне должны быть механизмы. Я думаю это оспариваемое утверждение. Но не в рамках данной темы.

Я просто повторю: кэш неизвестного или очень большого размера с политикой write back программно не обойти, любая запись может надолго остаться в кэше без попадания в общую память, а любые повторные чтения (или чтения ранее записанных данных) могут выдаваться из кэша, даже если в общей памяти данные уже давно другие. Без сигналинга об изменении или синхронизации никак, и никакие высокоуровневые механизмы (включая и транзакции) не помогут, вот тут и требуется поддержка на низком уровне. Например варианты MESI для кэшей.

bondkim137 в сообщении #1335465 писал(а):

надо, что б прочитав галочку, вычислитель B не достал из кеша каку вместо сообщения.

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

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

[bondkim137]

Dmitriy40 в сообщении #1335597 писал(а):

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

Вы меня не совсем поняли. В общем случае мы не знаем (за исключением сигналинга, который пока за скобками) - сообщение другому вычислителю пишется или просто временные данные для себя. Хочется кеш, который в обоих случаях будет работать корректно. И не хочется при сообщениях полностью кеши скидывать, ведь они могут активно кешировать значительный объем временных данных для себя.

Dmitriy40 в сообщении #1335597 писал(а):

Ваши слова "мол пускай пишут что хотят и в любом порядке" для меня звучат дико

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

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

[Dmitriy40]

Вон оно что, да, я понял неправильно.

bondkim137 в сообщении #1335618 писал(а):

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

Как вариант хранить одну структуру MESI в общей памяти для всех блоков общей памяти и использовать атомарные операции модификации её (читать можно и обычными) или другие методы синхронизации доступа. Зависимость от количества вычислителей линейная, за исключением модификации блока, который есть у других в их кэше, тут уж без широковещательности не обойтись, впрочем её можно организовать как список в общей памяти изменившихся блоков (которые были в состоянии S и только нём), который каждый вычислитель проверит по получении сигнала или по таймауту, модификация его тоже должна быть защищена, блок из него удалять когда он меняет состояние с M на другое (E или I). Причём сверхлинейная зависимость будет кажется лишь для операций чтения списка, записи в него останутся линейными. Ну и размер списка на практике не будет сильно превышать количество вычислителей, а часто и вообще пустой, ведь в нём хранятся лишь блоки, перешедшие S->M и только пока остаются в состоянии M. Может даже имеет смысл разделить состояние M на два по типу перехода в него: из S или из E/I. Тогда и список не нужен, можно по таймауту проверять состояние блоков из своего кэша, не стали ли они вдруг S->M, тут уж смотря что проще проверить, список блоков в состоянии S->M или таблицу MESI для всех блоков в кэше.
Да, смысл M тут несколько другой, не как в MESI протоколе, это скорее флаг что данный блок кем-то изменяется в его локальном кэше. После сброса изменений в общую память блок перейдёт в E (если останется в кэше писавшего в него) или I. Подразумевается что блок в состоянии M может быть лишь у одного вычислителя, остальные должны у себя его молча удалить (не трогая MESI инфу о нём) при первой возможности. Да и I тоже означает что блок никем не используется.
Ой, что-то я уже запутываюсь ...