Объясните, пожалуйста, что из себя представляют read barrier и write barrier, которые упоминаются в описаниях алгоритмов сборки мусора.
Например, при описании GO GC от Google написано, что write barrier — это небольшая функция, которая гарантирует, что чёрные узлы не ссылаются на белые.
А как это выглядит в ассемблерных командах, и если команд в такой функции несколько — то почему не возникает гонок (race conditions)
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Объясните, пожалуйста, что из себя представляют read barrier и write barrier, которые упоминаются в описаниях алгоритмов сборки мусора.
Вкратце, барьеры нужны чтобы гарантировать, что операции чтения/записи начатые до/после барьера завершаться-до/начнутся-не-раньше барьера. Причём здесь алгоритмы сборки мусора — не понятно, ведь это имеет отношения к любым параллельном алгоритмам с доступом к общему ресурсу типа память.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>Причём здесь алгоритмы сборки мусора
вот тут чуток про GO и барьеры :
https://golang.org/src/runtime/mbarrier.go
это просто имплементация барьеров в рантайме GO, я так думаю
