Параллельное программирование *

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

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

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

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

В силу философского закона единства и борьбы  противоположностей, когда есть одно, то должно быть и другое. Так, если есть свет, то, как ни крути, будет и тьма. Когда есть хорошее, то рано или поздно, как ни избегай, будет и плохое (жизнь, как известно, в полоску). А если есть последовательное программирование, то должно быть, как его ни назови, альтернативное ему - параллельное. А если уж оно есть или, как минимум, обсуждается, то необходимо дать ему определение, аналогичное по смыслу моделями обычных алгоритмов. Все это естественно и даже очевидно, когда речь идет о научных понятиях и, как в нашем случае, о науке программирования.

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

Все, что связано с картинкой, сделать не так уж сложно. Это довольно подробно описано в цикле статей по реализации графики в ВКПа (см. [2]). Для этого, во-первых, нужно создать графическое окно, установив данную картинку в качестве фона. Во-вторых, воспользоваться существующими заготовками контролов (элементов графического интерфейса), которые необходимо будет разместить на данном фоне.

Три способа менять один объект из нескольких потоков. Больше нет

Mutex, CAS, акторы, STM, CRDT, иммутабельность, MVCC, Disruptor…

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

На самом деле их ровно три. Всё остальное — реализации и комбинации.

Эта статья — попытка навести порядок в голове. После неё вы сможете:

за 5 секунд классифицировать любой подход к конкурентности;
понимать, почему Erlang выбрал акторы, а Java предлагает synchronized;
не изобретать велосипеды и не зацикливаться на «единственно правильном» решении;
проектировать многопоточный код, держа в голове простую модель.

Заодно, покажу почему ООП вообще не было изначально спроектировано под многопоток.

Задача Эдсгера Дейкстры о философах – великая задача великого программиста. Уж сколько лет, а она актуальна. Решая ее, прикасаешься к этому величию. И вот, перефразируя известное, «давно не было такого и вот опять», можно познакомиться с ее «новым прочтением» на Хабре[1].

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

Познакомился с проблемой обедающих философов – Dinning Philosopher Problem (DPP), я более двадцати лет тому назад (про DPP см. [2]). Результатом стала статья, в которой философы выполняли поставленную задачу, как минимум, не хуже, чем классические алгоритмы сортировок[3]. Позднее был сделан доклад на конференции по параллельным вычислениям в Саратове, где на суд научной общественности была предъявлена модель автоматных параллельных вычислений и пример ее приложения - задача Дейкстры[4].  

Замечание 1. В рамках обсуждения статьи на Хабре было проигнорировано  предложение поручить сортировку философам. Зря, конечно, т.к. надо же как-то убедиться, что предлагаемое решение работает хотя бы в первом приближении. К примеру, тот же DeepSeek, моментально выдавший свое решение DPP, так и не смог заставить их сортировать.

Не знаю, считается ли данная задача решенной, но то, с чем я знаком, по большей части беглое рассмотрение проблем, которые она отражает. У задачи есть теория, которая представлена монографией Хоара[5], или моделями сетей Петри у Питерсона[6] и В.Е. Котова[7] или другими подобными публикациям. Но, повторюсь, все это по большей части достаточно краткий анализ свойств модели и/или даже конкретного решения. Статья на Хабре из этой же серии. Все это ни как не окончательное решение описываемых ею проблем параллелизма. Правда, может, [авторами] вопрос так и не ставился, но все же ответ на него весьма желательно иметь.

В этой статье изложено всё, что нужно знать об устройстве компьютера с точки зрения программиста. Сюда входят сведения о том, для чего нужен тактовый генератор, регистры, кэши и виртуальная память; что такое архитектура процессора; что такое машинный код и код ассемблера; чем отличается компиляция в машинный код в C, C++ или Rust от компиляции в байт-код виртуальной машины в языках типа Java и C#; в чём их отличие от интерпретируемых языков вроде JavaScript или Python; что такое динамические и статические библиотеки (.dll/.so, .lib/.a); что такое фреймворк; что такое API и web-API; и что собой представляет параллельное программирование с использованием многоядерных процессоров, векторных регистров и видеокарт.

Хочу поделиться с вами заметкой о своем опыте написания с нуля примитивов синхронизации на чистом Go, совместимых c реализациями из стандартной библиотеки.

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

Команда Go for Devs подготовила перевод статьи, в которой автор шаг за шагом решает классическую задачу об обедающих философах на Go. Вы узнаете, почему наивный подход ведёт к взаимной блокировке, как нарушить симметрию, чтобы избежать deadlock’а, и почему даже «рабочее» решение может оставить одного философа голодать вечно.

Сообщество DotNetRu совместно с издательством «Питер» завершило перевод книги Нира Добовицки «C# Concurrency». Мы тщательно выверили терминологию, сгладили стиль и сохранили точность оригинала. Это практическое руководство для тех, кто хочет уверенно проектировать конкурентные компоненты на .NET 8/9 — без догадок и шаманства.

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

Недавно на Youtube появилась документалка о Python. Примерно в середине ленты есть драматический эпизод о том, как переход от Python 2 к 3 разделил сообщество (спойлер: в конечном итоге этого не случилось).

Первые версии Python 3 (3.0-3.4) в основном делали упор на стабильность и упрощение перехода пользователей с версии 2.7. В 2015 была выпущена версия 3.5 с новой фичей: ключевыми словами async и await для выполнения корутин.

Миновало десять лет и девять релизов, через считанные недели выпустят финальную версию Python 3.14.

Пока все отвлеклись на фичи разноцветного REPL в 3.14, в release notes появились серьёзные заявления, связанные с конкурентностью и параллелизмом.

Привет, Хаброжители! Асинхронные и многопоточные программы могут выполнять несколько задач одновременно, не теряя скорости или надежности. Но правильная организация параллельного выполнения может вызвать затруднения даже у опытных разработчиков. Эта практическая книга научит вас создавать параллельные приложения на C#, работающие с максимальной скоростью и не имеющие взаимоблокировок и других проблем синхронизации, которые ухудшают производительность и требуют огромных усилий для их обнаружения.

«C# Concurrency» помогает получить полное представление об особенностях многопоточности и асинхронного программирования. В ней особое внимание уделено практическому использованию операторов async/await в C# для упрощения асинхронных задач. Вы научитесь избегать распространенных ошибок, обходить классические проблемы многопоточности, такие как состояния взаимоблокировки и гонки, а также узнаете о многих сложных нюансах управления потоками и использования потокобезопасных коллекций.

Многопроцессорный вычислительный комплекс (МВК) «Эльбрус-2», созданный в СССР в 1984–1985 годах, является выдающимся достижением советской вычислительной техники и заслуживает высокой оценки по ряду ключевых параметров — числу процессоров, архитектуре и производительности, существенно опережающим многие зарубежные аналоги своего времени.

В статье рассматривается библиотека на C++, которая предназначена для реализации технологии параллельного автоматного программирования (АП), отвечающей концепции среды ВКПа (подробнее о ней см. [1]). Для полного понимания материала рекомендуется ознакомиться с основами теории АП, представленной в статьях [2, 3, 4], Взаимосвязь машины Тьюринга с конечными автоматами (КА) подробно рассмотрена в [5]. Вопросы применения корутин в контексте автоматного программирования анализируются в статьях [6–9]. Но в минимальном варианте достаточно даже общего представления о модели конечного автомата и принципах объектного программирования.

Event Sourcing и CQRS — это мощные архитектурные подходы, которые заменяют традиционное CRUD-управление состоянием на журналирование событий и разделение операций записи и чтения для масштабируемости и надежности. Вместо прямого изменения данных система сохраняет каждое изменение как событие, что обеспечивает полный аудит, контроль конкурентности и гибкость в обработке данных.

Экспериментируем с компилятором для новой не Фон-Неймановской архитектуры, обещающей повышение энергоэффективности в 100 раз.

Добавляем щепотку векторного программирования в задачки проекта Эйлер. Заодно разбираемся, как эффективно реализовать деление на константу.

Перед тем как перейти к рассмотрению предложенных изменений в работе асинхронности в C#, давайте разберемся — зачем все это нужно, как устроено сейчас и какие имеются проблемы, раз разработчики начали искать способы улучшения существующей логики.

Для начала давайте поймем, а зачем вообще нам нужна асинхронность и какие проблемы она решает?

Представим какой‑то абстрактный web‑api, который ходит за данными в БД. При однопоточном синхронном выполнении следующий запрос может быть обработан только тогда, когда полностью был выполнен предыдущий, что неэффективно, т.к. вся нагрузка ложится только на 1 ядро процессора, а остальные простаивают.

Несмотря на то, что сам я ушел из большого ООП¹ более десяти лет назад, причем, надеюсь, навсегда, я всегда крайне вяло и неохотно участвую в баталиях тупоконечников и остроконечников: я абсолютно убежден, что для разных типов задач лучше подходят разные инструменты, и выхолощенное ФП заставит всех вокруг создавать тонны никому не нужного бойлерплейта для тривиального круда, а кристальное ООП — воткнет все возможные палки в колёса при реализации бизнес-процессов. Любой из современных языков программирования позволяет смешивать эти подходы, а микросервисная архитектура — даже гостеприимно приютит несколько языков и сред под одной крышей.

Тем не менее, хотя я никогда не считал себя евангелистом функционального подхода, и уж, тем более, не примыкал к стану воинствующих пуристов, меня постоянно свербил вопрос: что же все-таки не так с ООП, если лично мне быстрее, проще и понятнее — реализовывать свои проекты на функциональном эликсире?

И вот, наконец, меня озарило. Объектная модель всем хороша в однопоточной среде. Даже банальная асинхронность приносит кучу совершенно нерелевантных проблем: мьютексы любого сорта — это порождение дьявола. В игрушечных примерах из книжек они езе как-то работают, но действительно _многопоточный_ код на них написать фактически нереально. Среда, которая буквально приглашает разработчика ошибиться и разрушить тотальность функций потенциальным дедлоком — не должна иметь права на существование в принципе.

Всем привет! Сегодня хочу поделиться с вами нашим опытом ускорения асинхронного микросервиса на Python примерно на 25%. Я расскажу, какие действия мы предпринимали с командой, что помогло, а что оказалось не особенно полезно с точки зрения ускорения сервиса.

Небольшое предисловие: мы в Иви постоянно работаем над тем, чтобы наши сервисы отвечали быстро и их максимальная предельная нагрузка повышалась. В процессе очередного анализа сервисов, мы выяснили, что один из них, о котором пойдет речь в статье, отвечает довольно медленно, учитывая его особенности. И мы решили его ускорять.

Поток — это последовательность элементов данных, предоставляемых за некоторое время. Концепция потока (stream) позволяет обрабатывать или передавать данные поэлементно, а не как одно целое. Потоки особенно полезны в сценариях, когда приходится работать с большими множествами данных, непрерывными данными или данными реального времени.

Потоки² — это просто состояния сохранения³ эмулятора⁴, связанные с условием, при котором продолжается их выполнение.