В чем плюс ассинхронного программирования?

Question

[beduin01]

Раньше я думал, что асинхронность нужна только медленному вебу, когда запрос не должен вешать всю остальную обработку. Однако оказалось что и для десктопа есть библиотеки вроде этой https://github.com/Reactive-Extensions/Rx.NET

Вопрос. В чем преимущества и недостатки у данного подхода? Код поддерживать сложнее становится? Где целесообразно применять, а где будет мешать?

Answer 1

[Stalker_RED]

Дело в том, что... нет никакого "синхронного" программирования. Процессор сам по себе - асинхронный. Там под капотом прерывания, переключения контекста, вот это всё. А синхронность - просто иллюзия, созданная для того, чтобы "облегчить" написание программ.

https://habrahabr.ru/post/216659/
https://habrahabr.ru/post/201826/

Comments

[lega]

> Процессор сам по себе - асинхронный. Там под капотом прерывания, переключения контекста, вот это всё.

Ну это как посмотреть, синхронное выполнение команд, команда за командой выполняется, а прерывание - это спец операция которая останавливает один синхронный поток команд и запускает другой, в итоге это можно назвать корутинами (а не асинхронщиной)

[nirvimel]

lega: В попытке развеять одни заблуждения создаются другие заблуждения. Это особенно касается статьи по первой ссылке. Что на самом деле хотел автор - разрушить представление о потоке ОС, как чем-то физически существующем и непрерывно выполняющемся во времени. Что в итоге получилось - он создал миф о некой "асинхронности", которая в действительности не более реальна чем "синхронность" - все это просто слова.
Человек, разбирающийся в архитектуре железа и ОС, смотрит на все эти buzzwords ("синхронность", "асинхронность", "короутины") как историк или религиовед смотрит на богов древней Греции. А не разбирающиеся в архитектуре спорят между собой о могуществе этих богов.

Answer 2

[nirvimel]

Реактивное программирование - еще один buzzword, под которым обычно понимается Модель акторов, еще один подход к параллельным вычислением, альтернативный классическим потокам (потоки, разумеется, используются внутри под капотом, но отсутствие необходимости в ручном использовании блокировок избавляет от многих потенциальных ошибок и тяжелых последствий в виде race conditions и deadlocks).

Все это имеет мало общего с асинхронностью в однопоточном (!) Javascript, которая не дает никакого распараллеливания вычислений.

Answer 3

[Андрей]

Десктопные приложения я писал очень давно, еще под DOS на Clipper 5.2, а до того вообще на Borland Pascal 6/7. Как только в коде появлялся мало-мальски долгоиграющий расчет, интерфейс зависал и интерактив сводился к нулю.

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

Comments

[Roman K]

Очень невзначай хвастанул.

[Андрей]

Да не такой уж я и старый, просто рано начал... :D

Answer 4

[res2001]

Преимущества асинхронного IO по сравнению с потоками в отсутствии накладных расходов на содержание потоков. Но программировать AIO довольно сложно, можно сравнить со сложностью программирования многопоточных/многопроцессных приложений.
Из жизни: апач - потоки, nginx - AIO. Т.е. при правильном подходе выигрыш от AIO выше, чем от потоков.
Использовать следует в приложениях, где много операций ввода-вывода.

Answer 5

[lega]

В чем плюс ассинхронного программирования?

Ни в чем, это просто необходимость для некоторых платформ (где нужно обруливать io блокировки) которые не умеют файберы/корутины/горутины и т.п. (т.е. синхронный стиль с неблокирующим io).