От чего защищает барьер LoadStore?
Или когда нам нужен LoadStore барьер?
По словам Дуга Ли,
(LoadStore) гарантирует, что данные Load1 будут загружены до того, как все данные, связанные с Store2 и последующими инструкциями сохранения, будут сброшены.
Итак, похоже, что результат load доступен только после завершения store.
В конце концов, результат load может быть устаревшим до последнего момента перед завершением работы магазина.
По моему мнению, этот барьер работает только для следующего шаблона:
load r1 [x1]; // load operation
#LoadStore barrier
store [y1] r2; // store operation
...
//other operations really need newest [x1]
...
Правильный ли этот пример? Пожалуйста, поправьте меня, если не так.
Кроме того, можете ли вы описать конкретную ситуацию, в которой возникает эта закономерность?
Я очень ценю любой совет или предложение.
Я думаю, что подойдет любой вид мьютекса. Поток 1: получить мьютекс, прочитать значение 1, прочитать значение 2, освободить мьютекс. Поток 2: получить мьютекс, сохранить значение 2, сохранить значение 1, освободить мьютекс. Освобождение мьютекса — это сохранение. Если загрузка значения 2 будет переупорядочена после освобождения мьютекса, поток 1 сможет прочитать значение 1 изнутри мьютекса и значение 2 снаружи мьютекса.
Почему это отмечено тегом x86? x86 не позволяет переупорядочивать LoadStore (за исключением хранилищ NT и/или загрузки NT из памяти WC). Это имело бы гораздо больше смысла для ARM или другой слабоупорядоченной ISA. preshing.com/20120930/weak-vs-strong-memory-models
@PeterCordes извини, я просто исправляю теги
Ответы 1
Кроме того, можете ли вы описать конкретную ситуацию, в которой возникает эта закономерность?
Предусмотрен список «прочитанных копий обновлений». Процесс получает текущую версию списка с «загрузкой» и «сохраняет» версию, чтобы зарезервировать ее в другой структуре или месте. После завершения процесс может использовать эту версию списка.
Важным моментом является то, что могут существовать разные временные порядки памяти. Таким образом, шаблон «загрузка хранилища» должен учитывать другие процессы обработки, осуществляющие доступ к той же памяти. В этом случае какое-либо обновление версии может вызвать несогласованность. Но в основном «загрузка/сохранение» сама по себе не является проблемой. Это глобальное управление информацией.
Я думаю, что есть много других моделей. Например, в статье доктора Алгава Herding Cats на рис. 4. есть несколько таблиц, которые должны быть знакомы со страницей модели памяти Java Дуга Ли, которую вы цитируете. В частности, «R/W» используется для буферизации загрузки (повторяющийся порядок «R/W») и других шаблонов, таких как причинно-следственная связь между записью и чтением. Если вы посмотрите главу 9, вы сможете найти ссылки на различные программы «C» с открытым исходным кодом, которые были просканированы на наличие этих шаблонов с помощью «cbmc» (похоже, что они также портированы на ebmc).
Если порядок инструкций будет изменен, другой поток может отреагировать на вновь сохраненное значение и изменить значение, которое вы собираетесь загрузить.