18.08.2020

Багатопотокова лінія – наступний рівень

Original: http://coopsoft.com/ar/mt_article.html

Менеджер резервних процесів

Кожен документ, який ви берете сьогодні, говорить про різання різьби, як ніби ми працюємо в текстильній фабриці. Використання слова «нитка» дуже популярне. Але ті, хто глибоко знає нитки, знають, що багатопоточна передача часто схожа на роман Стівена Кінга – у тіні повзають речі, які можуть вас укусити. Ця стаття розкриває моторошних сканерів багатопотокової передачі, представляє рішення у вигляді менеджера бекенд-процесів і доставляє вибійний удар з набором проектів з відкритим кодом. (2200 слів)

Едвард Харнед (Edward Harned) 
Старший розробник, Cooperative Software Systems, Inc.
Листопад 2002 р.

Вступ

Багатопотокова лінія – це точно майбутнє.

Архітектура процесорів IBM® Power4® (як і Power3® та PowerPC®) рекомендує багатопотокові програми для спільного зберігання. Тепер із технологією Hyper-Threading від Intel® на процесорах Xeon® і новому Pentium® P4 з’являться все нові і нові додатки, які потребують багатопотокової передачі.

Хоча сервери прикладних програм (JBoss™), безумовно, лідирують у висококласних серверних обчисленнях, є всюдисущі невеликі серверні та клієнтські машини, які відчайдушно потребують багатопотокової роботи.

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

Потік
Ви знаєте, як починати і закінчувати нитки. Ви знаєте, як керувати однією ниткою. Але чи знаєте ви, як керувати середовищем з декількома нитками?

Багатопотокова лінія має тінь

Коли ви запускаєте нитку виконання, то, що ви насправді робите, це запустити бекенд-процес (деякі операційні системи називають потоки легкими процесами.) Подумайте про бекенд-процес як про щось, що відбувається в іншій кімнаті вашого будинку. Ти сидиш у вертепі, а нова нитка працює в підвалі. Що це там робиться? Це ще живе? Що сталося з останнім запитом, на який я попросив його працювати?

Кожен резервний процес повинен вирішувати ці поширені проблеми з ниткою:

  • Що робити, якщо нитка висить у нескінченному циклі?
  • Що робити, якщо нитка ненормально закінчується?
  • Що робити, якщо нитці потрібна сама нова нитка?
  • Що робити, якщо потік створює / знищує накладні помилки вниз на обробку додатків?
  • Що робити, якщо нитка потребує часу?
  • Що робити, якщо Система більше не може обробляти потоки? (див. бічну панель)
    Це проблема перевантаження потоків (тобто там, де виконується стільки потоків, що Система більше не може підтримувати потоки, або ці потоки викликають стільки конкуренції за ресурси, що навколишнє середовище ефективно зупиняється.)
  • Який статус поточного запиту?
  • Який статус попереднього запиту?
  • Де скупчення?
  • Як сповістити когось про помилку в потоці?
  • Як виявити та відновитись із кіосків?
  • Як налаштувати це середовище з декількома нитками?
  • Як інші можуть дізнатися про загальне здоров’я навколишнього середовища?
  • Яким чином середовище різьблення може затихнути та вимкнутись витончено?
  • Цей список можна продовжувати і продовжувати.

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

Методи потоків

Зазвичай існує три класи потоків додатків:

  1. Ручні потоки
  2. Басейни потоків
  3. Керовані потоки

Ручні потоки

Ручний потік – це будь-який потік, який програма починає та керує собою. Стандартна нитка слухача – це найпоширеніша ручна нитка. Додаток запускає слухач. Слухач реєструється в Системі. Коли є робота, слухач повідомляє програму. Це основний сценарій однієї нитки для одного завдання, чистий і простий

Басейни потоків

Басейни потоків корисні для виконання фонових завдань, коли є кілька запитів на послуги, і потоки не блокують один одного.

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

Там, де пули потоків часто виходять з ладу – це складне додаток, будь то клієнт або сервер.

Поширене комплексне застосування – це те, що має кілька компонентів. Наприклад, для задоволення запиту клієнтська програма повинна отримати доступ до трьох різних файлів. Спробуйте передбачити логіку, необхідну для програми для планування трьох потоків (по одному для кожного доступу до файлу), дочекайтеся завершення кожного потоку та об’єднання повернених об’єктів з цих трьох потоків. Тепер додайте логіку для відновлення після відмови в будь-якому з цих потоків. Чи можете ви бачити, що відсутність прямого доступу до цих потоків (як це було б в ручних потоках) може ускладнити відновлення помилок, якщо не неможливо?

Візьміть наведений вище приклад і поставте його на сервер. Сервер має чергу запитів та десять потоків у пулі. Один з методів доступу до файлів має помилку і висить нитку. Перший запит надходить, і система планує три потоки (по одному для кожного доступу до файлу.) Два повних і один висить. У басейні залишилось лише дев’ять ниток. Це триває, поки в пулі не залишиться жодної теми. Сервер більше не працює.

Керовані потоки

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

Менеджер резервних процесів

Обробка бекенда настільки поширена, що ви, мабуть, ніколи не знали, що вона має назву.

Ви коли-небудь замовляли в ресторані, що приймає замовлення? Службовець, який приймає ваше замовлення, не є особою, яка заповнює це наказ.

  • Діловод передає наказ керівнику кухні.bp1.gif (2494 bytes)
  • Менеджер кухні розділяє замовлення на його складові частини (м’ясо, картопля, овочі) і розміщує кожен запит на компоненти в чергу для обробки окремим кухарем.
  • Коли кожен кухар закінчує страву, кухар кладе блюдо в мішок, передає мішок назад до керівника кухні, а потім отримує черговий запит з черги.
  • Коли замовлення завершено, керівник кухні передає мішок дільниці, яка вам його віддає.

Переваги:

    • Ефективність – замовлення заповнюється паралельно. Всі компоненти готуються одночасно.
    • Масштабованість – під час великих навантажень керівник кухні може легко додати більше кухарів саме там, де вони потрібні. Якщо нам потрібно три кулінари на м’ясо і один кухар для овочів, це зробити просто.
    • Простота – кожен кухар повинен розуміти лише один вид страви. Кухар-вегетаріанець не потребує занять м’ясом.

Фронтальна обробка – це спосіб функціонування більшості програм.

  • Службовець (GUI або аналізатор командного рядка) готує (окремі потоки) одинbp2.gif (1734 bytes)компонент за часом (лінійне програмування).
  • Коли перший компонент закінчить приготування (обчислення), другий може початися.
  • Наступне замовлення може не розпочатися до завершення всіх компонентів попереднього замовлення.

Недоліки:

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

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

  • вони переповнені ниткамиbp3.gif (2112 bytes)
  • нитка створення/знищення накладних витрат погіршує їх обробку
  • аномально закінчуються потоки не мають відновлення
  • загальну пам’ять не можна ділити між потоками
  • деякі функції потребують часу, а інші потребують автономної обробки
  • список продовжується і продовжується

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

Основи
Ключовим фактором для створення менеджера процесів бекенда є:

  • щоб відокремити логіку різьблення від логіки програми,
  • індивідуально контролювати кожну нитку і
  • створити інтерфейси GUI та не-GUI у середовищі.

Це звучить досить просто. Принаймні, поки ми не спробуємо. Менеджер критичних місій, що відповідає процесам, повинен відповідати на всі найпоширеніші проблеми з ниткою вище та мати можливість:

  • компоненти (запит з декількох частин),
  • рекурсія (коли необхідні вкладені рівні доступу),
  • стійкість (для спільних об’єктів між потоками),
  • динамічна зміна середовища (для зміни параметрів потоку, кількості запитів на очікування тощо),
  • розширення до базової логіки (гачки запуску/вимкнення),
  • ведення журналів (помилок та подій),
  • і, ніколи не забудьте налагодження.

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

Тінь, частина II

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

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

Отже, хто збирається написати багатопотокову синхронізовану інфраструктуру? Хто такі люди, які розуміють бібліотеки pthread, переключення контексту тощо? Зазвичай це робиться сторонніми розробниками (консультантами та/або незалежними постачальниками програмного забезпечення). Тоді хто збирається підтримувати код? Якщо сторонні люди переходять на зелені пасовища, то цей чудовий, ефективний, багатопотоковий, синхронізований код тепер є проблемою бізнес-орієнтованого персоналу. Темна хмара страху перед будь-яким менеджером бізнес-підрозділу.

Прийнятне рішення

Єдиний справді прийнятний підхід – це відкритий код. Таким чином, стандартну версію можна підтримувати величезною базою програмістів, і люди можуть адаптувати код до власних програм.

Рішення – Tymeac; набір проектів з відкритим кодом, розміщених на SourceForge.net: (див. Ресурси для завантаження)

TymeacSE для Java™ Standard Edition.
TymeacME для Java™ Micro Edition.
(the original, TymeacTS для платформи IBM® CICS®)
(Версії Both .Net™ і C/C++ у розробці.)

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

Tymeac обробляє всі проблеми багатопотокового середовища як як сервер, так і як вбудована структура черги та нитки для клієнтів. Природно, вона комплектується великою документацією.

Висновок

Програмне забезпечення для багаторізкових різьб необхідне для того, щоб скористатись процесорами IBM® “Power” процесорів та технологією Hyper-Threading Intel®.

Менеджер резервних процесів необхідний для створення ефективного багатопотокового програмного забезпечення.

Відкритий код – найкращий спосіб створити менеджер процесів бекенда.

Tymeac – найкращий з відкритим кодом, гроші менеджера бекенд-процесів купити не можуть.

Ресурси

  • Хостинг для проектів Tymeac знаходиться на веб-сайті SourceForge.net.
    http://sourceforge.net/
  • Завантажте окремі проекти:
    TymeacSE для Java™ Standard Edition.
    http://sourceforge.net/projects/tymeacse/
    TymeacME для Java™ Micro Edition.
    http://sourceforge.net/projects/tymeacme/
    TymeacTS для платформи IBM® CICS®
    http://sourceforge.net/projects/tymeacts/
  • Сервіси розробника Intel®, потоки
    http://cedar.intel.com/cgi-bin/ids.dll/topic.jsp?catCode=CDN

    • Використання кількох потоків у .Net Apps від Джона Шарпа
    • Як визначити ефективність технології Hyper Threading у програмі Шона Кейсі
    • плив технології Hyper Threading на багатопотокові побудови програмних додатків від Срі Сіамалакумарі
    • Підвищення продуктивності програми за допомогою технології Hyper Threading Роджера Сміта
    • Засоби масової інформації за технологією Hyper Threading, Єн-Куанг Чен, Метью Холліман, Ерік Дебес, Сергій Желтов, Олександр Князєв, Станіслав Братанів, Роман Беленов — Мікропроцесорні дослідження, Лабораторії Intel Labs
      Ізмаїл Сантос — Software Solutions Group, Корпорація Intel
  • Про зменшену версію повнофункціонального менеджера процесів бекенда, Tymeac дивіться в попередній статті Еда про роботи розробника — База сервера RMI

Про автора

З моменту свого академічного впровадження в чергу та підзадачі Едвард Харнед активно відстоював свої таланти з багатопотоковою та багатообробною обробкою. Спочатку він керував проектами як працівник у великих галузях, а потім працював незалежним консультантом. Сьогодні Ед є старшим розробником компанії Cooperative Software Systems, Inc., де впродовж останніх п’яти років він використовував програмування Java, щоб наблизити рішення для резервного процесу для широкого кола завдань.

About The Author

admin

Comments are closed.