Рубрика «multithreading» - 3

Разработка многопоточного кода — это сложное занятие. Действительно сложное. К счастью для упрощения жизни разработчиков давным-давно придуманы высокоуровневые абстракции, например, task-based parallelism, map-reduce/fork-join, CSP, actors и т.д.

Но когда попадаешь на профильные форумы, где общаются C++ники, то складывается ощущение, что многие просто не в курсе наличия чего-то более простого и удобного, чем std::thread в купе с std::mutex+std::condition_variable. Регулярно встречаются вопросы из категории: «Мне нужно запустить несколько рабочих потоков, в одном делается то-то, во втором то-то, а в третьем то-то. Я их запускаю вот так, а информацией между потоками обмениваюсь вот так. Правильно ли я делаю?»

Очевидно, что такие вопросы задают новички. Но, во-первых, количество неопытной молодежи в разработке софта всегда было велико, и с ростом привлекательности отрасли ИТ это количество только увеличивается. При этом печально, что новички знают про std::thread и std::mutex, но не знают про готовые инструменты, которые могли бы упростить им жизнь (вроде Intel TBB, HPX, QP/C++, Boost.Fiber, FastFlow, CAF, SObjectizer и т.д.).

И, во-вторых, среди ответов на такие вопросы довольно редко встречаются советы «возьмите вот этот готовый инструмент, ваша задача с его помощью решается всего в несколько строчек». Гораздо чаще люди обсуждают низкоуровневые детали самодельных реализаций thread-safe очередей сообщений.

Все это наводит на мысль о том, что имеет смысл на простых примерах показывать, как конкретный фреймворк может помочь в решении даже небольших и, казалось бы, несложных задач, связанных с многопоточностью. Поскольку мы развиваем SObjectizer как раз как инструмент для упрощения разработки многопоточных приложений на C++, то сегодня попробуем показать, как реализованные в SObjectizer-е CSP-шные каналы способны избавить разработчика от части головной боли при написании многопоточного кода.
Читать полностью »

О чем эта статья?

Одной из основных отличительных черт C++ного фреймворка SObjectizer является наличие диспетчеров. Диспетчеры определяют где и как акторы (агенты в терминологии SObjectizer-а) будут обрабатывать свои события: на отдельной нити, на пуле рабочих нитей, на одной общей для группы акторов нити и т.д.

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

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

Преамбула

Недавно один из пользователей SObjectizer-а рассказал про специфическую проблему, с которой ему довелось столкнуться в процессе использования SObjectizer-а. Смысл в том, что на базе SObjectizer-овских агентов разрабатывается приложение для управления подключенными к компьютеру устройствами. Часть операций (а именно операция инициализации и переинициализации устройства) выполняется синхронно, что приводит к блокировке рабочей нити на некоторое время. Операции же ввода-вывода осуществляются асинхронно, поэтому иницирование чтения/записи и обработка результата чтения-записи выполняются значительно быстрее и не блокируют рабочую нить надолго.
Читать полностью »

Многопоточность на корабликах - 1

Задача производитель/потребитель

Статья рассчитана для новичков, которые недавно начали свое знакомство с миром многопоточноcти на JAVA.
Читать полностью »

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

До версии Python 3.5 было два способа реализации параллельной обработки операций ввода-вывода. Нативный метод — использование многопоточности, другой вариант — библиотеки типа Gevent, которые распараллеливают задачи в виде микро-потоков. Python 3.5 предоставил встроенную поддержку параллелизма с помощью asyncio. Мне было любопытно посмотреть, как каждый из них будет работать с точки зрения памяти. Результаты ниже.
Читать полностью »

Когда летом 2016-го года создавалась первая статья про SObjectizer мы говорили, что со временем будем рассказывать и о деталях его реализации, дабы заинтересованные читатели могли заглянуть «под капот». Сегодняшняя статья будет как раз про потроха SObjectizer-а. Про механизм mbox-ов («почтовых ящиков»), который используется для организации взаимодействия акторов (агентов в нашей терминологии).

Почему речь именно про mbox-ы?

Потому, что мы сами удивлены, насколько много очень похожих вопросов вызывает этот механизм у тех, кто берется изучать SObjectizer. Оказалось, что вещь, хорошо знакомая, понятная и привычная нам, разработчикам SObjectizer, отнюдь не является таковой для новичков. Ну а раз так, то давайте попробуем разобраться, что же из себя представляют mbox-ы и как же они работают. А заодно и попробуем сделать свой собственный mbox.

Зачем нужны mbox-ы?

Почтовые ящики в SObjectizer нужны для того, чтобы организовывать взаимодействие между агентами. Общение между агентами строится посредством асинхронных сообщений и эти самые сообщения нужно куда-то отсылать. Возникает вопрос: «Куда именно?»
Читать полностью »

Если вы новичок в общении с RxJava или пытались разобраться в этом, но не довели дело до конца, то ниже вы найдете для себя кое-что новое.

image
Оригинал статьи написан 29 ноября 2017. Перевод вольный.
Читать полностью »

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

В данной статье приводится пример использования Akka в Spring-приложении, что представляет некоторую сложность, поскольку в силу ее особенностей, акторов нельзя создавать посредством простого вызова new.
Читать полностью »

Раньше мы рассказывали про SObjectizer как про акторный фреймворк для C++, хотя в действительности это не совсем так. Например, уже давно в SObjectizer есть такая классная штука, как mchain-ы (они же каналы из модели CSP). Mchain-ы позволяют легко и непринужденно организовать обмен данными между рабочими потоками. Не создавая агентов, которые нужны далеко не всегда. Как раз на днях довелось в очередной раз этой фичей воспользоваться и упростить себе жизнь за счет передачи данных между потоками посредством каналов (т.е. SObjectizer-овских mchain-ов). Так что не только в Go можно получать удовольствие от использования CSP. В C++ это так же возможно. Кому интересно, что и как, прошу под кат.

Читать полностью »

Корни SObjectizer берут свое начало в теме автоматизированных систем управления технологическими процессами (АСУТП). Но использовали мы SObjectizer в далеких от АСУТП областях. Поэтому иногда возникает ностальгия из категории «эх, давно не брал в руки шашек...» Однажды из-за этого в составе SObjectizer появился один из самых объемных примеров — machine_control. Уж очень тогда захотелось «тряхнуть стариной», смоделировать задачку управления оборудованием на современном SObjectizer-е. Ну и под шумок запихнуть в пример разные вкусные фичи SObjectizer-а вроде фильтров доставки, шаблонных агентов и диспетчера с поддержкой приоритетов. Сегодня попробуем рассказать и показать, как это все работает.

The Engine Room - Steel Stacks, Bethlehem, PA
Photo by Mike Boening

Читать полностью »

[Питер] Встреча JUG.ru c легендой параллельного программирования Maurice Herlihy — Transactional Memory and Beyond - 1

У нас праздник! В начале июля в Санкт-Петербурге пройдет SPTCC 2017, летняя школа по параллельному программированию. Одним из лекторов школы станет Морис Херлихи (Maurice Herlihy), легенда параллельного программирования, один из авторов знаменитого учебника «The Art of Multiprocessor Programming».

В четверг, 6 июля, в 19:00 в Университете ИТМО Морис выступит на встрече JUG.ru. На этот раз мы будем говорить не про Java. Тема встречи — транзакционная память.

О чем же нам расскажет Морис?

Транзакционная память

Новое поколение процессорных архитектур предоставляет нам аппаратную транзакционную память (Hardware Transactional Memory — HTM), механизм синхронизации для быстрых транзакций в оперативной памяти. В данном докладе будет показано, что HTM это не просто более быстрый путь для релизации старых-добрых monitor-ов и latch-ей. На самом деле, HTM обеспечивает фундаментальные позитивные изменения в том, как мы программируем многоядерные машины (и возможно даже базы данных), позволяя нам переосмыслить базовые примитивы синхронизации, такие, как lock-и, управление памятью, и многообразие многопоточных структур данных.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js