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

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

Таким образом, если вас интересуют общие проблемы параллельных процессов, то в этой и в последующих статьях на примере логических процессов мы их и рассмотрим. Терминологически мы будем придерживаться словаря по вычислительной технике под редакцией В.Иллингоута[1].  Но это может быть учебная литература, подобная [2], научная литература, как монография  [3], или научно-популярные книги типа [4, 5].

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

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

В настоящее время многоядерные процессоры с гетерогенными архитектурами, в которых сочетаются ядра с различной производительностью, становятся всё более и более распространенными. Если ещё пару лет назад такие архитектуры были в основном распространены в мобильном сегменте (см. ARM BIG.little), то с анонсом в 2022 году компанией Intel процессоров 12-го поколения линейки Intel Core, такие процессоры стали распространяться в сегменте десктопов и рабочих станций. Однако, до сих пор остается открытым вопрос — необходимо ли каким‑то специальным образом учитывать особенности данных архитектур для достижения максимальной многопоточной производительности?

Команда Spring АйО подготовила перевод статьи в которой автор разбирает, где параллельные стримы действительно масштабируются, а где создают накладные расходы, конкуренцию за ресурсы и иллюзию производительности. Коротко: сначала аналитика и измерения, потом — параллелизм.

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

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

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

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

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

Команда Go for Devs подготовила перевод статьи о самых коварных и трудноуловимых гонках данных в Go. Автор показывает на реальных примерах, как даже опытные разработчики легко попадают в ловушки конкурентности: от случайных захватов переменных в замыканиях до неправильного срока жизни мьютексов и скрытых гонок в стандартной библиотеке.

Подготавливая статью [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 ядро процессора, а остальные простаивают.