CPU, Memory Models, Concurrency, Multiprocess, Multithreading и Async. Часть 15. Выводы про модели памяти в железе + Bonus

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

Цели которые я ставил перед собой делая ответвление от привычных постов:
🔵 Продемонстрировать что может произойти под капотом программы в которой отсутствует синхронизация и всё отдано на откуп железу. Подсветить зачем нужны те самые мьютексы и семафоры и почему без их использования в программах всплывают неприятные артефакты.
🔵 Продемонстрировать два разных подхода к работе с памятью. К слову, теперь вы знаете один из факторов почему Macbook на M процессоре работает быстрее чем на Intel процессоре. Слабая модель памяти накладывает меньше ограничений на компилятор и параллельное исполнение, что выливается в увеличение производительности. Но за всё нужно платить, особенно на уровне железа. Трейдофф между безопасностью и производительностью на лицо.

Чуть более глубокие обзорные статьи для устаканивания информации из постов:
📄 x86 TSO: A Programmer's Model for x86 Multiprocessors
📄 Hardware Memory Models
📄 Lock-free структуры данных. Основы: Модель памяти с примерами на C++
📄 В чём опасность слабой модели памяти ARM на примере конкретного эксплоита
📄Consistency Models

Если хочется основательно погрузиться в вопрос:
📖 A Primer on Memory Consistency and Cache Coherence, Second Edition

Спасибо что читали, в следующих постах приступим к разбору моделей памяти и конкурентности в языках программирования😇