Ещё прочитал статьи:
https://research.swtch.com/mm
tldr
1) Классические примеры хардварной модели памяти, и какие исполнения допускают процессоры.
2) Почему несмотря на относительную простоту 1) все на самом деле сложно: оптимизации компиляторов, необходимость или relaxed atomic-ов или валидности программ с data race
3) Собственно про изменения которые они планируют в golang.
Из интересного:
1. В отличие от Java/JavaScript, они явно утверждают, что если в программе обнаружится гонка то программа может сообщить о ней и упасть, а не как-то "не очень опасно" работать
2. Оказывается разработчики архитектур думают о нас простых смертных и делают seq_cst/java volatile более дешёвым с точки зрения исполнения, например на armv8 acq_rel ~ seq_cst для load/store, как следствие наверно в будущем все сведётся к наличию seq_cst и relaxed(unsync) атомикам. Потому что кажется, без последних достаточно сложно обеспечить хорошую производительность некоторых thread safe структур данных/статистики