Эта статья описывает использование улучшенного социального подхода к программированию SOSAL в реальных проектах и ситуациях, а также содержит рекомендации для более эффективного применения этих принципов. Скорее под кат!

Всем привет! 

Начну с предыстории.

Когда мы в Амазоне планировали переносить сервис с x86/64 на ARM, почему-то никто в нашей команде не поднял тему того, что надо уделить особое внимание работе с многопоточностью и синхронизацией, так как из-за того, что у этих двух архитектур разные модели памяти, могли случиться неожиданные проблемы.

Однако, на тот момент я тоже об этом не знал, и нам повезло, что мы изначально везде использовали модель памяти Sequential Consistency (что это – далее в статье), поэтому все прошло гладко. Теперь, зная про модели памяти и возможные последствия, боюсь представить, что было бы в противном случае.

Как родилась статья

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

Статья основана на материалах лекции Computer Science Center (CSC) с курса “Параллельные вычисления” преподавателя Калишенко Е.Л. Крайне рекомендую ознакомиться со всеми лекциями курса (более структурированного материала по теме я еще не встречал). Благо он в открытом доступе – ссылка.

Что такое барьеры памяти и зачем это все нужно?

Начнем с небольшого описания того, как устроена “условная” архитектура процессора. Почему условная? Потому что может отличаться в зависимости от конкретной реализации, но суть похожа. 

Представьте, что вы сидите на скучнейшем уроке литературы: кто-то спит, кто-то рисует в тетради, кто-то чатится в ICQ, кто-то проходит очередной уровень Gravity Defied, а вы люто набираете на своём Sony Ericsson программу на Бейсике, которая случайным образом выводит имя одного из одноклассников и какой-нибудь слегка обидный неправдивый факт о нём. Наконец, последние строчки дописаны, вы запускаете программу и показываете её соседу по парте, потом телефон уходит на другой ряд и… к концу урока добрая половина класса уже потирает ладони, чтобы хорошенько отвесить вам подзатыльников за такие приколы. Но последствия не так важны, как эйфория от того, что путь мобильной разработки для вас только-только начинается.

Это был 2006 год. У многих из нас ещё не было ПК, зато были мобильные телефоны с небольшими экранами, ограниченный доступ в Интернет и много свободного времени, которое хотелось потратить на реализацию какой-нибудь идеи.

Я часто критикую небезопасные при работе с памятью языки, в основном C и C++, и то, как они провоцируют необычайное количество уязвимостей безопасности. Моё резюме, основанное на изучении доказательств из многочисленных крупных программных проектов на С и С++, заключается в том, что нам необходимо мигрировать нашу индустрию на безопасные для памяти языки по умолчанию (такие как Rust и Swift). Один из ответов, который я часто получаю, заключается в том, что проблема не в самих С и С++, разработчики просто неправильно их готовят. В частности, я часто получаю в защиту C++ ответ типа: "C++ безопасен, если вы не используете унаследованную от C функциональность" [1] или аналогичный, что если вы используете типы и идиомы современного C++, то вы будете застрахованы от уязвимостей типа повреждения памяти, которые терзают другие проекты.

Хотелось бы отдать должное умным указателям С++, потому что они существенно помогают. К сожалению, мой опыт работы над большими С++ проектами, использующими современные идиомы, заключается в том, что этого даже близко недостаточно, чтобы остановить наплыв уязвимостей. Моя цель на оставшуюся часть этой заметки - выделить ряд совершенно современных идиом С++, которые порождают уязвимости.

Введение