Верес Д. С. МОДЕЛЬ АКТОРІВ ЯК ПІДХІД ДО РОЗРОБКИ БАГАТОПОТОЧНИХ ДОДАТКІВ

УДК: 004.057.5+004.053

 

МОДЕЛЬ АКТОРІВ ЯК ПІДХІД ДО РОЗРОБКИ БАГАТОПОТОЧНИХ ДОДАТКІВ

Верес Д. С.

Національний технічний університет України «Київський політехнічний інститут», Київ, Україна

 

У той час, як необхідність написання програмних додатків, здатних експлуатувати багатопроцесорні архітектури сучасних комп'ютерів, стає все більш актуальною, паралельне програмування часто сприймається як складне завдання. Причиною цьому служить низькорівневість розповсюдженої нині моделі потоків, використання якої призводить до складності коду та поганої масштабованості. Модель акторів може бути використана як основа для моделювання, розуміння і аргументації в широкому спектрі паралельних систем.

Ключові слова: багатопоточність, модель акторів, потоки виконання

 

Верес Д. С. Модель актеров как подход к разработке многопоточных приложений / Национальный технический университет Украины «Киевский политехнический институт», Киев, Украина

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

Ключевые слова: многопоточность, модель актеров, потоки выполнения

 

Veres D. S. Actor model as approach for multythreaded application development / The National Technical University of Ukraine “Kyiv Polytechnic Institute”, Kyiv, Ukraine

While the necessity of writing software applications capable of exploiting the multi-processor architecture of today computers is more and more common, concurrent programming is often perceived as an hard task. The reason for this is the low level of common nowadays threads model, the use of which leads to code complexity and poor scalability. Model actors can be used as a basis for modeling, understanding and reasoning in a wide range of parallel systems.

Key words: multythreading, actor model, execution threads

 

Незважаючи на повсюдне поширення і ексклюзивну підтримку на багатьох платформах, модель паралелізму, що заснована на потоках операційної системи, має ряд принципових недоліків, які ускладнюють написання коректних і масштабованих паралельних програм.

По-перше, програмісту доступний лише найнижчий рівень абстракції для обміну даними між паралельно виконуваними задачами - розділений стан (shared state). У такій моделі додатково до роботи з даними кожна задача повинна докладати зусилля з координації цієї роботи з іншими завданнями. Головна проблема тут у тому, що програмісту необхідно дуже детально описати логіку роботи та координації, що в свою чергу створює семантичний розрив між людським і комп'ютерним уявленням програми. Цей розрив знижує ефективність вираження думок, погіршує читабельність коду і в підсумку призводить до помилок в програмі (гонки за даними (contentions, races), взаємні блокування (deadlocks), погана масштабованість).

По-друге, в операційних системах Windows занадто великі витрати на запуск потоку ОС, що робить непрактичним або неможливим розбиття програми на велику кількості паралельно функціонуючих елементів. Але значна кількість програм (веб-додатки, системи реального часу тощо), навпаки, потребують одночасного запуску якомога більшої кількості виконавців. Тому, і тут ми спостерігаємо семантичний розрив, який змушує програміста вручну підтримувати відображення логічних потоків на потоки фізичні. Це призводить до таких складних рішень, як модель Файбер SQL Server, в яких кожна упущена дрібниця може мати катастрофічні наслідки.

Поводячи проміжний підсумок, можна помітити, що в силу своєї низькорівневості модель потоків не надто добре підходить для програмування людиною - звідси випливають проблеми, з якими зазвичай стикаються розробники при написанні паралельних програм. Один з виходів з цієї ситуації - використання високорівневих моделей, які дозволяють людське розуміння програми більш просто виразити в програмному коді. Однією з таких моделей є модель акторів.

У 1973 році Карл Хьюітт з колегами випустили роботу "A Universal Modular Actor Formalism for Artificial Intelligence", в якій представили підсумок багаторічної роботи дослідників з MIT Artificial Intelligence Laboratory – "a modular actor architecture and definitional method for artificial intelligence that is conceptually based on a single kind of object: actors".

У такій архітектурі обчислення реалізуються набором акторів, кожен з яких:

1. Має ідентифікатор, за яким він може бути пізнаний і адресований іншими акторами.

2. Вміє спілкуватися з іншими акторами шляхом посилки і отримання повідомлень, причому для набору відправлених повідомлень гарантується тільки сам факт їх доставки адресатам, але не порядок їх отримання.

3. Реалізує свою поведінку в реакціях на що надходять повідомлення.

4. Має недоступне для зовнішнього світу стан, який може впливати на його поведінку.

5. У відповідь на деяке повідомлення може виконати довільну комбінацію наступних дій:

• змінити свій стан;

• змінити логіку обробки подальших повідомлень;

• послати одне або декілька асинхронних повідомлень;

• створити одного або кількох нових акторів;

• завершити свою роботу.

Як можна бачити, модель акторів дуже схожа на модель об'єктів в об'єктно-орієнтованому програмуванні, де:

1. Програма представляється у вигляді набору однорідних взаємодіючих сутностей.

2. Стан кожної сутності інкапсульований всередині і доступний тільки тими способами, які дозволить власник.

3. В процесі виконання програми поведінка сутностей може змінюватися.

Залишаючи за кадром математичні теорії, за допомогою яких можна формальним чином робити висновки про системах акторів, розглянемо модель акторів як цінну абстракцію розробки паралельних програм.

На практиці актор реалізується у вигляді сутності, у якої є стан, поведінку і поштова скринька (mailbox) - асинхронна черга необроблених повідомлень (зазвичай поштова скринька підтримується бібліотекою виконання, а програміст працює з нею неявно за допомогою конструкцій відправки та отримання повідомлень - в деяких мовах навіть є спеціальні оператори send і receive).

Програма в моделі акторів представляється у вигляді набору паралельно працюючих сутностей. Так як потенційно таких сутностей може бути дуже багато, то використовуються техніки планування на рівні користувача (user-mode scheduling), які полягають в тому, що запуском акторів на виконання керує не операційна система, а середовище виконання (runtime). В операційних системах Windows такий підхід можна реалізувати за допомогою Файбер і UMS API.

Спрощено типовий алгоритм планувальника середовища виконання можна описати таким чином: процесорний час ділиться на кванти, які по черзі відводяться акторам в системі; у разі, якщо актор вичерпав свій квант часу, або ж, якщо виявиться, що після обробки чергового повідомлення поштова скринька актора порожня, планувальник призупиняє поточного актора і запускає на виконання наступного.

Модель акторів можна реалізувати на будь-якій популярній мові програмування, але, як і у випадку з функціями вищого порядку, певні можливості мови та стандартної бібліотеки можуть зробити використання цієї методики зручнішим. З таких можливостей можна відзначити:

1. Зіставлення з шаблоном (pattern matching) для зручної фільтрації повідомлень.

2. Оголошення власних операторів для наочного запису шаблонів комунікації між акторами (наприклад, в F # можна визначити оператори "<-" і "<->" для, відповідно, надсилання повідомлення і надсилання з наступним очікуванням відповіді).

3. Підтримку співпрограми для полегшення реалізації планувальника (наприклад, в C # можна використовувати оператори yield return і yield break для повернення управління планувальником з можливістю подальшого поновлення виконання з місця зупинки).

4. Наявність асинхронних API типових операцій на зразок роботи з файлами і мережею для запобігання блокування всієї системи одним-єдиним актором, що очікує результату тривалого синхронного виклику.

На платформі. NET перевагами моделі акторів можна скористатися за допомогою спеціальної мови програмування Axum, а також на звичних C# і F# (у разі F # буде набагато менше синтаксичного шуму, який ховається за вбудованими в мову монадами і зіставленню за шаблоном).

Отже, модель акторів - високорівневий підхід для створення паралельних програм, що володіє великим потенціалом для вирішення практичних завдань. З точки зору прикладного програмування, цей підхід побудований на наступних базових принципах:

1. Наявність легковагих процесів, що не прив'язаних до потоків ОС.

2. Можливість асинхронної передачі повідомлень між процесами.

3. Відсутність даних, що розділяються між процесами і, отже, неможливість взаємного блокування.

Як ми бачили на прикладі, паралельні програми, розроблені з використанням акторів, зручні в написанні і супроводі, а також принципово не містять проблем з гонками і взаємними блокуваннями, які характерні для традиційної методології. Тут можна провести аналогію з функціональної чистотою - за рахунок записи в спеціальному вигляді програма отримує властивості, корисні і для людини, і для комп'ютера.

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

 

Література:

1. F# Actors Revisited: [Електронний ресурс] – Режим доступу: http://codebetter.com/matthewpodwysocki/2009/05/20/f-actors-revisited/

2. Actors that Unify Threads and Events: [Електронний ресурс] – Режим доступу: http://lampwww.epfl.ch/~phaller/doc/haller07actorsunify

3. Concurrency in Erlang & Scala: The Actor Model: [Електронний ресурс] – Режим доступу: http://savanne.be/articles/concurrency-in-erlang-scala/

4. We haven’t forgotten about other models – honest: [Електронний ресурс] – Режим доступу: http://blogs.msdn.com/b/maestroteam/archive/2009/02/27/we-haven-t-forgotten-about-other-models-honest.aspx

 

References:

1. F# Actors Revisited: [Electronic resource] – Access mode: http://codebetter.com/matthewpodwysocki/2009/05/20/f-actors-revisited/

2. Actors that Unify Threads and Events: [Electronic resource] – Access mode: http://lampwww.epfl.ch/~phaller/doc/haller07actorsunify

3. Concurrency in Erlang & Scala: The Actor Model: [Electronic resource] – Access mode: http://savanne.be/articles/concurrency-in-erlang-scala/

4. We haven’t forgotten about other models – honest: [Electronic resource] – Access mode: http://blogs.msdn.com/b/maestroteam/archive/2009/02/27/we-haven-t-forgotten-about-other-models-honest.aspx

Site search

Конференции

Please publish modules in offcanvas position.