Прочитал статью «Математика для программиста». Удивительно, что в ней куча букв, но нет внятного смысла. Я решил исправить этот фатальный недостаток.

Привет, это Григорий Демченко из WhatsApp. Мой доклад посвящён использованию сопрограмм в C++20. Я не стал говорить про низкоуровневые примитивы и то, как компилятор поддерживает сопрограммы и преобразовывает соответствующий код. Вместо этого акцент сделан на практическом применении сопрограмм для решения конкретных задач высокопроизводительных масштабируемых систем. Это именно то, ради чего создавались сопрограммы в новом стандарте, и то, с чем разработчик будет иметь дело в процессе проектирования и программирования. Я постарался рассмотреть конкретные примеры и проблемы, с которыми можно столкнуться при использовании полностью асинхронного подхода.

— О чём я сегодня расскажу? Первое — введение в асинхронность. Далее мы рассмотрим примитивы, которые можно использовать в новом стандарте, и интеграцию с планировщиками. Также немаловажным аспектом будет являться работа со старым кодом, если мы пишем новый код с использованием нового подхода. Затем я покажу бонус, достаточно интересный и необычный. И подведём итоги того, что у нас получилось.

Эта статья — реакция на другую статью Производительность главнее всего. Да, в интернете опять кто-то не прав. Однако я хочу несколько выйти за рамки обсуждаемой темы, чтобы дополнить и углубить рассмотрение важных аспектов.

Оригинальная статья Кнута

Конечно, Кнут не нуждается в том, чтобы его кто-то защищал. В самом деле, кто такой Кнут, а кто такой я? Однако моя цель — не защита Кнута, а защита здравого смысла.

Оказывается, что контекст статьи очень важен. Поэтому приведу ссылку, чтобы читатель мог самостоятельно ознакомиться с оригиналом статьи: http://cowboyprogramming.com/files/p261-knuth.pdf

Итак, перед нами статья 1974 года Стенфордского Университета под названием “Структурное программирование с оператором GOTO” (здесь и далее перевод авторский). Меня еще не было, а статья уже была. Я подозреваю, как и многих из вас, читающих статью.

Мое внимание привлекла статья: Самая реалистичная интерпретация квантовой механики.

На хабре крайне мало толковых статей по физике, поэтому мне было чрезвычайно интересно, что же такого нового содержится в статье про квантовую механику. Тем более, что некоторые моменты квантовой механики я изучал достаточно глубоко.

Давайте приступим к анализу содержимого.

Анализ

нарушение неравенств Белла закрыло подобным моделям путь в квантовую механику. Но только если не брать во внимание одну лазейку...

Начало крайне интригующе. Сразу хочется разобраться с этой лазейкой и понять суть. Однако дальнейший рассказ забывает про эту лазейку.

Недавно вышла статья, мимо которой я сначала решил пройти, но потом решил написать развернутый комментарий в виде очередной статьи.

Программист должен решать проблемы бизнеса
Программист не должен решать задачи бизнеса

Я почти согласен с авторами обеих статей, однако есть несколько нюансов, о которых я хотел бы поделиться.

Уровни разработчиков

Начну я, пожалуй, с вопросов иерархии и уровней. Раньше я думал, что существует 3 уровня:

Чем больше читаю про ООП, тем больше возникает ощущение, что ООП понимают не только лишь все. Очередная статья этому пример.

Тут можно долго расписывать нелепость аргументаций в приведенной выше статье. Но в целом, всю статью можно перечеркнуть буквально следующим.

Старое место работы. Все сборы позади. Последний рабочий день. Осталось сдать ноутбук, предварительно подчистив данные на нем. Закрываешь крышку. Все, ты готов к последнему шагу: к пьянке с теперь уже бывшими коллегами и, возможно, друзьями. К тебе смущенно подходит близкий коллега и спрашивает: "ну и куда ты теперь?". И ты объясняешь ему, куда. Попутно помогают тебе раскупорить шампанское или пиво. И вот ты уже наливаешь себе бокал и понимаешь, что завтра ты уже здесь работать не будешь. Тебе грустно, но надо двигаться дальше, ведь это твой выбор...

Ты знаешь, что ты оставил кучу незакрытых задач. Их невозможно все закрыть: все время добавляются новые и новые. У тебя всегда были дедлайны. Ты бы и с радостью сделать все правильно и хорошо, чтобы не стыдно было за свой код. Чтобы можно было гордиться и говорить — это я написал. Но дедлайны и обещания… Они все портили. Приходилось срезать углы и вколачивать костыли буквально кувалдой, чтобы хоть как-то заработало. Но теперь уже это в прошлом. Пусть другие люди разгребают это, я умываю руки. Вперед, к новому коду, к новом команде. Уж там-то все будет по феншую и как надо.

Предисловие

Эта статья является реакцией на статью: Что будет с обработкой ошибок в С++2a. После каждого абзаца у меня появлялся зуд, открывались зарубцованные раны и начинали кровоточить. Может, я принимаю слишком близко к сердцу то, что написано. Но просто хочется выть о той близорукости и безграмотности, что проявляют программисты на С++ в 21 веке. Причем даже не в его начале.

Приступим.

Классификация

Условно все ошибочные ситуации в программе можно разделить на 2 большие группы:

1. Фатальные ошибки.
2. Не фатальные, или ожидаемые ошибки.

Преамбулка

Эта статья является анализом другой статьи: Если вы не нанимаете джунов, то не заслуживаете сеньоров

Стоит сразу оговориться, что я понятие не имею, что там и как в Netflix. Просто стало обидно за здравый смысл и логику, над которыми автор так похабно издевается на протяжении всей статьи.

Я оставил по возможности оригинальное оформление, а свои комментарии отметил отдельно.

Ну и желтый заголовок тоже оставил, немного видоизменив.

Поехали.

Введение

Решил проанализировать статью, описывающую некоторые интересные детали потоковой обработки ровно один раз: exactly-once. Дело в том, что некоторые авторы очень странно понимают термины. Разбор статьи как раз позволит прояснить многие детали более глубже, т.к. выявление нелогичностей и странностей позволяет более полноценно прочувствовать понятия и смысл.

Приступим.

Анализ

Начинается все очень даже неплохо:

Аннотация

Обработка данных в реальном времени ровно один раз (exactly-once) — задача крайне нетривиальная и требующая серьезного и вдумчивого подхода на всей цепочке вычислений. Некоторые даже считают, что такая задача невыполнима. В реальности хочется иметь подход, обеспечивающий отказоустойчивую обработку вообще без каких-либо задержек и использование различных хранилищ данных, что выдвигает новые еще более жесткие требования, предъявляемые к системе: concurrent exactly-once и гетерогенность персистентного слоя. На сегодняшний день такое требование не поддерживает ни одна из существующих систем.

Предложенный подход последовательно раскроет секретные ингредиенты и необходимые понятия, позволяющие относительно просто реализовать гетерогенную обработку concurrent exactly-once буквально из двух компонент.

Введение

Разработчик распределенных систем проходит несколько стадий:

Стадия 1: Алгоритмы. Здесь происходит изучение основных алгоритмов, структур данных, подходов к программированию типа ООП и т.д. Код исключительно однопоточный. Начальная фаза вхождения в профессию. Тем не менее, достаточно непростая и может длиться годами.

Стадия 2: Многопоточность. Далее возникают вопросы извлечения максимальной эффективности из железа, возникает многопоточность, асинхронность, гонки, дебагинг, strace, бессонные ночи… Многие застревают на этом этапе и даже начинают с какого-то момента ловить ничем не объяснимый кайф. Но лишь единицы доходят до понимания архитектуры виртуальной памяти и моделей памяти, lock-free/wait-free алгоритмах, различных асинхронных моделях. И почти никто и никогда — верификации многопоточного кода.

Стадия 3: Распределенность. Тут такой треш творится, что ни в сказке сказать, ни пером описать.

Предисловие

Недавно прочитал очередную статью из серии: "мы лучше двухфазного коммита". Здесь я не буду анализировать содержания этой статьи (хотя, подумываю о том, чтобы дать развернутый анализ). Задача моего опуса — предложить самый эффективный вариант распределенного коммита с точки зрения временных задержек. Конечно, такой коммит дается высокой ценой. Однако цель — дать оценку и показать, что двухфазный коммит не является тормозным, как многие считают.

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

Предисловие

Эта статья является продолжением цикла статей про асинхронность:

1. Асинхронность: назад в будущее.
   
2. Асинхронность 2: телепортация сквозь порталы.
   

Спустя 3 года я решил расширить и обобщить имеющийся спектр асинхронного взаимодействия с использованием сопрограмм. Помимо этих статей также рекомендуется ознакомиться с универсальным адаптером:

1. Универсальный адаптер
   

Введение

Рассмотрим электрон. Что он из себя представляет? Отрицательно заряженная элементарная частица, лептон, обладающий некоторой массой. Это означает, что он может участвовать по меньшей мере в электромагнитных и гравитационных взаимодействиях.

Предисловие

Данная статья является авторским переводом с английского собственной статьи под названием God Adapter. Вы также можете посмотреть видео выступления с конференции C++ Russia.

1 Аннотация

В статье представлен специальный адаптер, который позволяет оборачивать любой объект в другой с дополнением необходимой функциональности. Адаптированные объекты имеют один и тот же интерфейс, поэтому они полностью прозрачны с точки зрения использования. Будет последовательно введена общая концепция, использующая простые, но мощные и интересные примеры.

2 Введение

ПРЕДУПРЕЖДЕНИЕ. Почти все методы, указанные в статье, содержат грязные хаки и ненормальное использование языка C++. Так что, если вы не толерантны к таким извращениям, пожалуйста, не читайте эту статью.

Термин универсальный адаптер происходит от возможности универсальным образом добавить необходимое поведение для любого объекта.

Краткое содержание

1. Фатальная ошибка Мартина Клеппмана.
   
2. Физико-химическая кинетика уделывает математику.
   
3. Период полураспада кластера.
   
4. Решаем нелинейные дифференциальные уравнения, не решая их.
   
5. Ноды как катализатор.
   
6. Предсказательная сила графиков.
   
7. 100 миллионов лет.
   
8. Синергия.
   

В предыдущей заметке мы подробно разбирали статью Брюера и его одноименную теорему. На этот раз займемся препарированием поста Мартина Клеппмана «The probability of data loss in large clusters».

В данном посте автор пытается промоделировать следующую задачу. Для обеспечения сохранности данных обычно используется метод репликации данных. При этом, на самом деле, не важно, используется ли erasure кодирование или нет. В оригинальном посте автор задает вероятность выпадения одной ноды, а затем ставит вопрос: а какова вероятность выпадения данных при увеличении числа нод?

Ответ приведен на этой картинке:

Введение

Давно хотел написать про мифы о CAP теореме, но как-то все не доходили руки. Однако, почитав очередной опус, схватился за голову и решил разложить все по полочкам, чтобы в мозгах возникла стройная картина.

Событие, когда какая-то статья вызывает бурю эмоций, — крайне редкое. Первый раз такое возникло, когда я прочитал про chained replication. Меня пытались убедить, что это мощный подход и что это лучшее, что могло произойти с консистентной репликацией. Я сейчас не буду приводить доводы, почему это плохо работает, а просто приведу говорящую цитату из статьи Chain Replication metadata management:

Split brain management is a thorny problem. The method presented here is one based on pragmatics. If it doesn’t work, there isn’t a serious worry, because Machi’s first serious use case all require only AP Mode. If we end up falling back to “use Riak Ensemble” or “use ZooKeeper”, then perhaps that’s fine enough.

В моем вольном пересказе это означает примерно следующее: "У нас тут есть некий алгоритм. Мы не знаем, будет ли он работать правильно или нет. Да нам это и не важно". Хотя бы честно, сэкономило кучу времени, спасибо авторам.

И тут, значит, попадается на глаза статья: Spanner, TrueTime & The CAP Theorem. Её мы разберем по полочкам ближе к концу, вооружившись понятиями и знаниями. А перед этим разберем самые распространенные мифы, связанные с CAP теоремой.

Предисловие. Данная публикация является авторским переводом собственной статьи. Поэтому если вы найдёте ошибку в переводе, то вполне может оказаться, что ошибка, на самом деле, в оригинальной статье.

Аннотация

1. Есть страдание.
2. Есть причина страдания.
3. Есть прекращение страдания.
4. Есть путь, ведущий к избавлению от страданий.

4 благородные истины буддизма

Настоящая статья содержит описание раннего прототипа, который вводит понятие реплицируемого объекта (replicated object) или сокращённо replob. Такой объект является дальнейшим переосмыслением борьбы со сложностью кода, возникающего при программировании распределённых систем. Replob устраняет зависимость от стороннего сервиса и реализует согласованное изменение любых пользовательских объектов, представляющих соответствующие данные и функциональность. Эта идея основана на использовании выразительности языка C++ и объектно-ориентированного подхода, что позволяет использовать сложную логику внутри распределённых транзакций. Это позволяет значительно упростить разработку отказоустойчивых приложений и сервисов. Последующие статьи будут более детально объяснять развиваемый подход.

Введение

ПРЕДУПРЕЖДЕНИЕ. Почти все методы, указанные в статье, содержат грязные хаки памяти и ненормальное использование языка C++. Так что, если вы не толерантны к таким извращениям, пожалуйста, не читайте эту статью.

На текущий момент, тематика, связанная с распределёнными системами, является одной из самых интересных, и привлекают большое количество людей, включая разработчиков и учёных. Популярность объясняется просто: мы должны создавать надежные отказоустойчивые системы, которые обеспечивают безопасную среду для выполнения различных операций и для хранения данных.

Не прошло и года, как я добрался до продолжения статьи про асинхронность. Эта статья развивает идеи той, самой первой статьи про асинхронность [1]. В ней обсуждается достаточно сложная задача, на примере которой будет раскрыта мощь и гибкость использования сопрограмм в различных нетривиальных сценариях. В заключение будут рассмотрены две задачи на состояние гонки (race-condition), а также небольшой, но очень приятный бонус.

Асинхронность… Услышав это слово, у программистов начинают блестеть глаза, дыхание становится поверхностным, руки начинают трястись, голос — заикаться, мозг начинает рисовать многочисленные уровни абстракции… У менеджеров округляются глаза, звуки становятся нечленораздельными, руки сжимаются в кулаки, а голос переходит на обертона… Единственное, что их объединяет — это учащенный пульс. Только причины этого различны: программисты рвутся в бой, а менеджеры пытаются заглянуть в хрустальный шар и осознать риски, начинают судорожно придумывать причины увеличения сроков в разы… И уже потом, когда большая часть кода написана, программисты начинают осознавать и познавать всю горечь асинхронности, проводя бесконечные ночи в дебаггере, отчаянно пытаясь понять, что же все-таки происходит…

Именно такую картину рисует мое воспаленное воображение при слове “асинхронность”. Конечно, все это слишком эмоционально и не всегда правда. Ведь так?.. Возможны варианты. Некоторые скажут, что “при правильном подходе все будет работать хорошо”. Однако это можно сказать всегда и везде при всяком удобном и не удобном случае. Но лучше от этого не становится, баги не исправляются, а бессонница не проходит.

Так что же такое асинхронность? Почему она так привлекательна? А главное: что с ней не так?

Введение

Данная статья является продолжением цикла статей: Использование паттерна синглтон [1], Синглтон и время жизни объекта [2], Обращение зависимостей и порождающие шаблоны проектирования [3], Реализация синглтона в многопоточном приложении [4]. Сейчас я хотел бы поговорить о многопоточности. Эта тема настолько объемна и многогранна, что охватить ее всю не представляется возможным. Здесь я заострю внимание на некоторых практичных вещах, которые позволят вообще не думать о многопоточности, ну или думать о ней в крайне минимальном объеме. Если говорить точнее, то думать о ней только на этапе проектирования, но не реализации. Т.е. будут рассмотрены вопросы о том, как сделать так, чтобы автоматически вызывались правильные конструкции без головной боли. Такой подход, в свою очередь, позволяет значительно уменьшить проблемы, вызванные состояниями гонок (race condition, см. Состояние гонки [5]) и взаимными блокировками (deadlock, см. Взаимная блокировка [6]). Этот факт уже сам по себе представляет немалую ценность. Также будет рассмотрен подход, который позволяет иметь доступ к объекту из нескольких потоков одновременно без использования каких-либо блокировок и атомарных операций!