🤔 Вы когда-нибудь задумывались, почему в Go, несмотря на все гарантии, иногда возникают неочевидные проблемы в многопоточном коде? Модель памяти Go — это мощный, но порой загадочный инструмент, который скрывает от нас низкоуровневые детали. И это не всегда хорошо.

Вторая часть статьи от Игоря Панасюка погружает нас в тонкости линеаризуемости исполнения, барьеров памяти и того, что происходит, когда в программе появляются data race.

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

Здесь — первая часть статьи.
А вот здесь — вторая часть.