×
Фото Почему асинхронность – это сложно?

Почему асинхронность – это сложно?

Что не так с асинхронностью? Почему программисты и студенты так плохо её понимают?

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

Мы не будем рассматривать примеры кода в данной заметке – сравнительно скоро появится пример реализации на Си, а также в рамках стартующего курса по Python мы напишем свой event-loop.

А теперь – асинхронность. Странно, что весь мир старается как-то синхронизироваться, для чего придумывает стандарты, общие системы мер, часовые пояса, а вот программистам подай асинхронность. Опять же нет олимпийской дисциплины "асинхронное плаванье" (хотя, я бы посмотрел под поп-корн), но есть синхронное.

Да даже в технологиях стараются синхронизировать движение различных деталей – вспомните те же паровозы: все колёса объединены, чтобы двигаться одновременно и с одной частотой. И IT-не исключение – зря что ли таймеры понатыканы в различные контроллеры? Или почему частота шины фиксируется?

Нет, асинхронность – это то, с чем борются. Но, видимо, получают какой-то профит, раз всё равно пользуются...

А пользуются неблокируемостью. И это более позитивное определение: наша задача не в том, чтобы двигаться не в такт, не в том, чтобы код колбасило – не дай бог попасть в резонанс с каким-то другим процессом. Наша задача – избавиться в обработке данных от ожиданий прихода / отправки данных.

И после подобного можно получить ответ студента, который слышал что-то про асинхронность: "С асинхронностью мы можем не ждать результата выполнения операции" – один из частых вариантов интерпретации этого подхода. Нет, здорово получается: купили мы товар у продавца, он ушёл на склад за товаром, или даже создал заявку на доставку из другого города... А мы ушли дальше без товара – купить то купили, а получить и пользоваться – для слабаков!

И тут надо добавить некоторое "как мы это делаем". По сути, цели наши не поменялись: нам всё также нужно получить тот товар. И мир не изменился – товар всё также далеко. Да и логистика та же – быстрее товар не доедет от того, что мы теперь пользуемся неблокирующим подходом. Меняется лишь наше отношение к этому: мы не остаёмся ждать, мы продолжаем заниматься нашими повседневными делами, временами (или по звонку продавца) заходя в магазин, чтобы узнать: приехала посылка или нет. И чтобы продавец нас узнал – показываем квитанцию об оплате, где указана наша посылка.

Это и есть наша "событийная петля". А квитанция – промис, футур и тому подобное.

Мы не можем начать пользоваться нашей покупкой раньше. По факту, мы её получим даже чуть позже – сидя дни напролёт около прилавка, мы получим своё быстрее всего. Но сколько мы потеряем времени? А вот заглядывая на обеде в магазин, мы можем получить посылку чуть ли ни на день позже... Но при этом живём полной жизнью!

Так что эта самая "вредная" асинхронность есть и в нашей жизни. Более того, она помогает комфортнее жить, когда все стороны взаимодействия готовы к такому подходу. Именно подходу, а не технологии. А раз это подход – он применим во многих сферах!

Комментарии

Фото
29 дней назад Valerii_Palych

Google. Асинхронность... Асинхронный код, асинхронное программирование, асинхронный двигатель... Три четких определения, не требующих для освоения особой одаренности. P.S. Продавец, прилавок, склад... Прочел раз, два... Почесал за ухом...

Фото
29 дней назад Гоша

Доброго дня! Рад, что Вы появились и указали на некоторое моё лукавство! Однако, то, что я говорю в начале заметки (о том, что асинхронность в жизни – нелепость и проблема), развенчивается в конце.

И да, определения – это хорошо, но они без примеров, без аналогий не дают понимания: как это устроено и зачем. Тот же гугл по "асинхронное программирование" выдаёт ссылку на medium с переводом статьи из "Node Hero" (как я понял):

Асинхронный ввод-вывод — это форма обработки ввода/вывода, позволяющая продолжить обработку других задач, не ожидая завершения передачи.

Дальше – функции, объекты, какой-то "фоновый режим". И да, заметьте, это определение очень схоже с тем, что я привёл выше. Я ведь слышал его на экзамене ни раз. А дальше – "а как же мы потом с данными работаем?", "откуда данные, если мы их не ждали"... Магия.

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

Если получилось криво / непонятно – грустно. Подумаю над другой аналогией.

Рад был Вас видеть!

Фото
29 дней назад Valerii_Palych

Здравия желаю -- Георгий! Вы напомнили мне мои студенческие годы и требования привязки эвольвентной зубчатой передачи к решению очередного пленума ЦК КПСС. Программист - синий воротничок, ему достаточно определения и примера с перечислением инструментария и задач решаемых асинхронным программированием. Инженеру нужны, опять же, четкие формулировки, методика и конкретные примеры механизмов с элементами асинхронности. Никакой магии. Ваша задача её развеять. Всё остальное придется изучать самостоятельно - в процессе деятельности, ежели вдруг понадобится... Жизнь коротка, очень - всё не успеть. P.S. Я, тоже всегда рад встрече. Ко мне в блог до сих пор наведывается наш общий знакомый Andry Max.

Нравится Disqus? – Пожалуйста!
Фото Что не так с Училищем и почему плохо сдают Petooh
Предыдущая запись:
Что не так с Училищем и почему плохо сдают Petooh
Фото Базовые примеры использования cURL
Следующая запись:
Базовые примеры использования cURL