Асинхронне програмування - це набагато більше філософія, ніж просто черговий фокус програмування. Хоча ваше останнє запитання привертало відповіді головним чином щодо аспектів програмування, і моя відповідь була відключеною самотністю, оскільки вона була переважно теоретичною, я намагаюся дати вам нове перспективне будівництво на тій же лінії, але пояснення, а не просто посилання.
У цьому йдеться про деякі основи того, як і як відбувається асинхронне програмування.
Припустимо, ви підете в пекарню (і припускаючи, що торт буде приготований після замовлення) - у вас є два варіанти, або ви вирішите почекати, поки торт буде готовий, або ви віддасте замовлення і повернетесь додому і забрати пізніше, коли вона буде готова. Перший (чекати) є синхронним методом, а пізніше - асинхронним . Зайве говорити, що цей приклад дає гарну інформацію про те, чому слід використовувати асинхронні методи над синхронними.
Програмування на основі подій - лише один із способів побудови асинхронних систем, і це не просто корисна модель дизайну, але, скоріше, це архітектурна схема. Я перераховую випадки, коли ця теорія використовується практично корисним способом - сподіваючись, що вона внесе певну ясність
Одним із перших прикладів асинхронних систем є система IO Unix. Хоча ми знаємо read(), write()і навіть select()виклики блокують потік програми, але всередині ОС вони асинхронні, тобто ядро, як правило, знає, що блоковий пристрій (він жесткий диск) потребує певного часу, щоб заповнити буфер, доти, поки процесор не буде вільним від цієї відповідної нитки, а значить, нитка розташована як (не готова). Посилання 1. Моріс Бах "Конструкція операційної системи Unix"
Ще один найпоширеніший приклад - більшість фреймворків інтерфейсу. Тут усі кліки користувачів спочатку надсилаються через контролер, який у свою чергу викликає відповідне додаток. Важливо, що такі зворотні дзвінки не повинні тримати зворотних дзвінків у режимі очікування, поки система замерзне. Зворотний виклик з контролера інтерфейсу на зворотні, як правило, асинхронний, якщо він передбачає важку обробку.
Ще одним хорошим прикладом асинхронного програмування (як чистого шаблону дизайну) є Active Object. Активний об'єкт - це той, у якого є своя приватна нитка, така що можна зберігати багато запитів у черзі та виконувати по одному. Зверніться до цієї статті: Активний об’єкт . Ця модель широко використовується прямо від програмного забезпечення Enterprise до мобільних рамок. Популярні платформи Java / EJB і .NET дозволяють викликати локальний або віддалений асинхронний метод, що по суті дозволяє нормальним об'єктам стати активними об'єктами. Активні об'єкти з'явилися ще в Symbian: Активні об'єкти в Symbian OS від Aapo Haapanen (див. Також: Активні об'єкти в Symbian ). Це зараз також присутнє в РосіїAndroid ).
Окрім «Активного об’єкта», той же автор Дуглас Шмітт створив ряд інших творів, які є іншими паралелями до об’єкта «Актив» і є також асинхронними зразками. Дивіться цю схему поводження з подіями, і повний рахунок доступний у його книжковій архітектурі програмного забезпечення, орієнтованої на візерунок: шаблони для одночасних та мережевих об'єктів - V2
Коли дані потреби об'єкта для повернення API, в той час як працюють у фоновому режимі , щоб реально виконати роботу, звичайна методика повинна мати систему многопоточную для досягнення цієї мети. Різьбові системи присутні скрізь від C (posix), C ++ ( boost ) до Java, C # тощо. Активний об’єкт - це по суті лише абстракція, яка може приховати це. Подивіться, чому втілення активних об'єктів є переважними над голою темою. Ще одне добре прочитане .
Але ця концепція виходить за межі потоків або об'єктів всередині програми, щоб стати асинхронною. Одне з найкращих способів використання в розподілених системах, де два додатки не обов’язково чекати один на одного координації. Старий добрий (чи не такий гарний, залежно від того, як би ви це подивилися) RPC був синхронним. [звичайно, є й інші асинхронні RPC ]. Але сучасні альтернативи, такі як Посереднє програмне забезпечення, орієнтоване на повідомлення , справді асинхронні з поважних причин.
Останнє, але може бути найцікавішим - це програмування Агентів, яка може скористатися асинхронною моделлю зв'язку .
Хоча асинхронне програмування виглядає сексуально, але це створює власну складність, включаючи:
- рамки для передачі поверненої вартості
- додаткові накладні комунікації
- додаткова потреба в синхронізуючих конструкціях
- можливість тупиків, перегонів тощо, якщо все зроблено не правильно.
... і так далі.
Його завжди слід використовувати лише з справжніх причин.
Тож коли слід використовувати Асинхронну модель? Коли слід помістити фонову нитку і дозволити абоненту переходити до асинхронності? Ось кілька хороших правил великого пальця, коли вона застосовується (але не є повною)
Коли система хоче застосувати сувору серйозну розмову про ресурси: наприклад, ви хочете зберегти абсолютну фіксовану кількість потоків. Асинхронний візерунок змушує систему реалізувати чергу.
Коли потреби абонента, які потрібно робити "інші корисні речі", справді є справжніми. Так багато разів інший потік, навіть якщо його розблокувати, не зробить нічого корисного і зависає навколо опитування для отримання результатів. Це дійсно може бути більш споживчим процесором, ніж основна синхронна модель.
Коли вам потрібні більш високі рівні надійності в розподілених системах. (див. Посереднє програмне забезпечення, орієнтоване на повідомлення ).