Коли вам знадобляться "сотні тисяч" ниток?

Erlang, Go і Rust всі так чи інакше стверджують, що вони підтримують паралельне програмування за допомогою дешевих "потоків" / процедур. У FAQ поширені запитання :

Практично створити сотні тисяч goututines в одному адресному просторі.

Rust Підручник каже:

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

Документація Ерланга говорить:

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

Моє запитання: який тип програми вимагає стільки одночасних потоків виконання? Тільки найзайнятіші веб-сервери приймають навіть тисячі одночасно відвідувачів. Програми типу «бос-працівник / диспетчер», які я писав, я писав про зменшення повернень, коли кількість потоків / процесів значно більше, ніж кількість фізичних ядер. Я думаю, це може мати сенс для чисельних програм, але насправді більшість людей делегує паралелізм третім сторонам бібліотекам, написаним у Fortran / C / C ++, а не цим мовам нового покоління.

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

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

Це може допомогти подумати про те, що Ерланг спочатку був розроблений, а саме - управління телекомунікаціями. Такі дії, як маршрутизація, комутація, збір / агрегація датчиків тощо.

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

Ця стаття може бути корисною.

Мовою, де вам заборонено змінювати змінні, простий акт підтримання стану вимагає окремого контексту виконання (який більшість людей називає потік, а Ерланг називає процес). В основному все - це робітник.

Розглянемо цю функцію Erlang, яка підтримує лічильник:

counter(Value) ->
    receive                               % Sit idle until a message is received
        increment -> counter(Value + 1);  % Restart with incremented value
        decrement -> counter(Value - 1);  % Restart with decremented value
        speak     ->
            io:fwrite("~B~n", [Value]),
            counter(Value);               % Restart with unaltered value
        _         -> counter(Value)       % Anything else?  Do nothing.
    end.

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

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

Моє запитання: який тип програми вимагає стільки одночасних потоків виконання?

1) Той факт, що мова "важить" означає, що є менше шансів, що вам доведеться скинути цю мову, коли все стане складніше в дорозі. (Це називається концепцією "Весь продукт".) Багато людей кидають Apache на Nginx саме з цієї причини. Якщо ви десь близькі до "жорсткої межі", накладеної накладними потоками, ви злякаєтесь і почнете думати про способи подолати це. Веб-сайти ніколи не можуть передбачити, скільки трафіку вони отримають, тому витратити трохи часу на те, щоб змінити масштабованість.

2) Одна програма на запит лише на початку. Існує маса причин використовувати горотини всередину.

• Розглянемо веб-додаток з одночасними запитами 100, але кожен запит генерує 100 запитів із зворотнього зв'язку. Очевидний приклад - агрегатор пошукових систем. Але майже будь-яка програма може створювати програми для кожної "області" на екрані, а потім генерувати їх самостійно, а не послідовно. Наприклад, кожна сторінка на Amazon.com складається з 150+ додаткових запитів, зібраних саме для вас. Ви не помічаєте, оскільки вони паралельно, а не послідовні, і кожна "область" - це власна веб-служба.
• Розгляньте будь-яку програму, де надійність та затримка є першорядними. Ви, мабуть, хочете, щоб кожен вхідний запит знімав декілька запитів, що повертаються , і повертати будь-які дані, що повертаються першими .
• Розгляньте будь-яке "приєднання клієнта", яке виконується у вашому додатку. Замість того, щоб сказати "для кожного елемента, отримати дані", ви можете розкрутити купу горотин. Якщо у вас є купа рабних БД для запиту, ви чарівно пройдете N час швидше. Якщо цього не зробити, це не буде повільніше.

зменшення повернень повертається, коли кількість потоків / процесів значно більше, ніж кількість фізичних ядер

Продуктивність не єдина причина розбиття програми на CSP . Це насправді може полегшити розуміння програми, а деякі проблеми можна вирішити набагато менше коду.

Як і у слайдах, зв'язаних вище, сумісність у вашому коді є способом організації проблеми. Не мати гороутин - це не мати структури даних Map / Dictonary / Hash на вашій мові. Ви можете обійтись без цього. Але як тільки у вас є, ви починаєте використовувати його скрізь, і це дійсно спрощує вашу програму.

У минулому це означало "прокатати своє" багатопотокове програмування. Але це було складно і небезпечно - все ще не так багато інструментів, щоб переконатися, що ви не створюєте перегони. І як завадити майбутньому технічному обслуговувальнику помилитися? Якщо ви подивитесь на великі / складні програми, ви побачите, що вони витрачають багато ресурсів у цьому напрямку.

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

Для Erlang прийнято мати один процес на з'єднання або інше завдання. Так, наприклад, потоковий аудіосервер може мати 1 процес на підключеного користувача.

Erlang VM оптимізований для обробки тисяч або навіть сотень тисяч процесів, роблячи контекстні комутатори дуже дешевими.

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

Простий приклад для Erlang, який був розроблений для спілкування: передача мережевих пакетів. Коли ви робите один http-запит, у вас можуть бути тисячі пакетів TCP / IP. Додайте до цього, що всі підключаються одночасно, і у вас є випадок використання.

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

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