Что такое memory barrier?

мне непонятна фраза
«нужно довести все треды до memory barrier. Это и есть stop-the-world»

Бессмысленная фраза без контекста.

Т.е. непонятно (на уровне ассемблера), что такое memory barrier, зачем он нужен, везде ли он есть...

На русском толкогого объяснения нет. Читай википедию. Хотя, по твоему уровню вопросов видно, что всё равно ничего не поймёшь.

мне непонятна фраза

> Бессмысленная фраза

а, ну тогда нормально, что она мне непонятна

по твоему уровню вопросов видно

а по этом твоему комментарию видно, какое ты хамло. Дружбомагии тебе.

друзняшка, это технический форум с чёткими ответами, а не чат знакомств. тебя, школьника, как и все вещи, называют своими именами.

Как сказал представитель Intel на одной конференции, в мире есть всего несколько (десятков?) специалистов, которые до конца понимают модели памяти в современных процессорах.

Поэтому не расстраивайся, если ничего не поймешь после прочтения статьи на википедии :)

тебя, школьника, как и все вещи, называют своими именами.

проблема не в этом. Проблема что на этом не останавливаются, а переходят к оскорблениям.

Что стоило ту последнюю фразу не писать? Даже время бы сэкономилось.

А что сложного-то во всяких cache coherence протоколах и подобной пурге? Любой EEшник это все знает.

уточни, EE - это execution engine (как в статье Влада Чистякова про сборку мусора - http://www.rsdn.ru/article/dotnet/GC.xml ) ?

EE - это всего лишь electric engineering. Архитектура cpu сейчас в любой EE курс любого ПТУ входит.

Ты бы ссылку на источник этой бредовой фразы привел. Вне контекста это полная чушь.

Осмелюсь предположить, что вопрос вырос из поста на хабре - http://habrahabr.ru/post/148322/

Видимо, вопрос в контексте сборки мусора.

Термин «memory barrier» применительно к GC имеет другой смысл, нежели термин «memory barrier» применительно к модели памяти.

Для GC memory barrier — это способ отследить чтение или запись в память. Используется для синхронизации сборщика мусора и пользовательского кода.

мне непонятно, как происходит это самое «отслеживание». Насколько я помню
во-первых, компилятор (или это jit?) размечает в коде специальные места, где можно запускать сборку мусора (как те места называются, кто их организовывает, как это выглядит для процессора)
во-вторых, не существует никакой специальной инструкции аппаратного процессора intel, в которую такое место могло бы скомпилироваться

А, ну так там автор - некомпетентное, лживое чмо, которое ни хрена не понимает в real time GC. Легко можно без остановок обходиться.

Т.е. непонятно (на уровне ассемблера), что такое memory barrier, зачем он нужен, везде ли он есть, как узнать дошла ли нить до него или нет, почему/как нить останавливается, когда доходит до memory barrier, что такое чекпоинты и чем они отличаются от вышеописанного.

На уровне ассемблера memory barrier, скорее всего, одна из следующих вещей:

1) проверка/выставление глобального/тредлокального флага 2) чтение/запись в страницу памяти, у которой хитрым образом управляют флагами доступа, чтобы в нужный момент доступ к памяти вызвал прерывание 3) патчинг кода на ходу

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

Механизм остановки нити может быть разным. Есть управление контекстом нити со стороны ОС (сигналы, ptrace, SuspendThread в win32), а также нить сама может остановиться на каких-либо примитвах синхронизации.

Чекпоинтом обычно называют точку в коде, когда известно состояние контекста нити (т.е., когда известно, какие регистры CPU содержат указатели, а какие --- не указатели, а также где на стеке расположены живые указатели). Чекпоинт обычно совмещен с барьером памяти, но не обязательно.

Например, барьер памяти на основе защиты страницы виртуальной памяти может сработать тогда, когда нить не находится в чекпоинте. В этом случае сборщик мусора должен каким-то образом «довести» нить до ближайшего чекпоинта. Например, в регистре EFLAGS в x86 можно поставить Trap Flag и подождать, когда нить доберется до чекпоинта. Или поставить точку останова - вариантов немало.

Грубо говоря, mutator не имеет права срать в страницу, которую не закончил размечать marker текущего поколения. Этого можно добиться применением write barrier интрукций, но на ламерских x86 это дорого.

во-первых, компилятор (или это jit?) размечает в коде специальные места, где можно запускать сборку мусора (как те места называются, кто их организовывает, как это выглядит для процессора)

Специальные места для процессора никак не выглядят. Они специальные только для сборщика мусора/компилятора. В этих местах можно анализировать содержимое регистров/стэка (так как не всегда можно просто посмотреть на регистр - там может содержаться промежуточное значение адресной арифметики или в стеке может быть невалидное состояние какой-нибудь переменной).

не существует никакой специальной инструкции аппаратного процессора intel, в которую такое место могло бы скомпилироваться

В x86 есть такая замечательная вещь, как виртуальная память. Страницы виртуальной памяти могут быть замаплены, размаплены, а также иметь защиту от чтения/записи.

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

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

вот это хорошее (понятное) объяснение. А какие ещё могут быть варианты реализации?

Царь, ты?

проблема не в этом. Проблема что на этом не останавливаются, а переходят к оскорблениям.

Тебя тут ещё никто не оскорблял.

В x86 есть такая замечательная вещь, как виртуальная память. Страницы виртуальной памяти могут быть замаплены, размаплены, а также иметь защиту от чтения/записи.

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

Я не знаю, чем это замечательно. С любовью SBCL к памяти было бы разумно использовать huge pages, но т.к. сборщик мусора шерстит всю тронутую страницу, то автоматически начинает жрать в 500 раз больше времени.

Кроме того, количество VMA в SBCL'ном процессе просто зашкаливает, что сильно замедляет все операции над картой памяти, а постоянные изменения этой самой карты вызывают сброс TLB на ядрах, где выполняются треды SBCL'ного процесса. Ну и вообще все ядра в системе по IPI дёргаются, это не есть хорошо.

По-моему, часть SBCL'ных тормозов обуславливается именно особенностью работы его GC. А в дальнейшем, с ростом размера оперативки, будет ещё хуже.

В общем, даже лень тебе что-то объяснять. Таких, как ты — миллионы, серых и отвратительных, как плевки на асфальте. Приходящих сюда ежедневно с ведром грязной воды, которой мыли полы, вместо мыслей. Вам все уже было сказано и не раз, поэтому и встречают тебя апатией и предложениями уйти.

С любовью SBCL к памяти было бы разумно использовать huge pages, но т.к. сборщик мусора шерстит всю тронутую страницу, то автоматически начинает жрать в 500 раз больше времени.

То, как SBCL работает с памятью - это печально. Много мелких маппингов, которые регулярно меняются - это, конечно, плохо. Да и хотя бы разобраться с консервативностью сборщика было бы неплохо.

Но использование одной страницы памяти с целью останова нитей - это малое зло.

Что касается непосредственно read/write barrier'ов, то моих знаний недостаточно, чтобы хотя бы перечислить нормальные способы реализации.

То, как SBCL работает с памятью - это печально.

А таки какие есть альтернативы? Как я понимаю, сборщику мусора по поколениям надо знать, обращались ли к объекту между вызовами, да? У шо, ставить на объекты специальный бит? Но это же дикий оверхед, не?

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

У меня ещё как-то желание было запустить Cheney GC на x86-64. По идее ему механизм со страницами/сегфолтами не нужен, да? Будут только минус нити и затык на проход GC.