Pull to refresh

Comments 25

UFO just landed and posted this here
Почему бы и нет? Количество «простых концепций», которые вам нужно знать, чтоб накодить что-нибудь по приближенным к запросам бизнеса задачам — будет исчисляться многими сотнями, а еще и связи между ними нужно осознавать. Если вам одну концепцию из нескольких сотен объяснят просто и на пальцах — почему бы вам не порадоваться минимальным затратам времени на её понимание?
А зачем человеку обязательно становиться разработчиком? Может, моя мама захочет тоже что-то накодить (разово) для своего блога, где она выкладывает рецепты, и ей просто нужно разобраться, не вникая в тонкости программирования, например.
Есть две группы программистов, которые знают что такое указатели и те что не знают что такое указатели.
Ждал увидеть описание как это работает изнутри, как исполняется на одном потоке и т.д.
По-моему только ленивый ещё статью о промисах в JS не писал.
ждем следующей статьи про map/filter/reduce
принцип асинхронного программирования: вам никогда не захочется сидеть сложа руки, просто ожидая чего-то, в то время как вы могли бы потратить свое время на какие-нибудь другие полезные дела
Комментарий не по теме статьи, слово заинтересовало. Синхронно — одновременно, совпадение по времени. Асинхронно — не одновременно, то есть в разные, не совпадающие отрезки времени, последовательно или вразнобой, без синхронизации.
Порезать овощи, потом поставить воду нагреваться — последовательно, события не связаны, в перерывах можно отвлекаться, нет синхронности.
Поставить воду нагреваться и, пока греется, начать резать овощи — одновременно, параллельно, то есть синхронизированно.
Однако, где-то произошло переворачивание смысла — распараллеливание назвали асинхронным подходом, хотя именно в этом случае процессы совпадают по времени. Синхронно с выполнением основного потока происходит ожидание события.
В компьютерном программировании, асинхронными событиями являются те, которые возникают независимо от основного потока выполнения программы. Асинхронные действия — действия, выполненные в неблокирующем режиме, что позволяет основному потоку программы продолжить обработку.
Говорим об отсутствии блокировки, начинаем ориентироваться на события — называем асинхронностью.
Сам подход (а также суть статьи) понятны полностью. Не понятно только использование именно этого слова. Понятно, что оно давно используется, привычно, не вызывает разночтений. Но не понятно, почему именно оно — как раз тот момент, который я не смог бы объяснить пятилетнему ребенку.

Синхронность не означает одновременность, синхронность означает упорядоченность по времени.


Порезать овощи, потом поставить воду нагреваться — последовательно, т.е. упорядоченность есть.


Поставить воду нагреваться и, пока греется, начать резать овощи — одновременно, упорядоченности нет: вода может нагреться независимо от того с какой скоростью мы режем овощи (по крайней мере, код на JS работает именно так).


А вот если резать овощи с натренированной фиксированной скоростью — процесс снова становится синхронным (и к тому же переходит в область "реального времени").

Синхронность не означает одновременность.
Разные словари утверждают обратное.
В контексте программирования да — синхронность стала синонимом последовательного, асинхронность стала синонимом параллельного. Но в контексте разглядывания этимологии и словарных значений наблюдается обратная картина, о чем я и написал комментарий.
Последовательный, блокирующий, упорядоченный, событийно-ориентированный — это не совсем про «хронос», другие слова. Просто любопытно, почему взято именно это слово, причем с переворачиванием значения на обратное. Возможно, здесь есть какой-то нюанс, который поможет мне лучше понять суть происходящего.
Синхронность — это же одновременность, здесь понимают не параллельное выполнение самих задач (тем более, что они могут быть разнородны), а одновременное завершение очередной задачи к началу следующей. Приёмы синхронизации, кстати, насильно приводят к совпадению этих точек.
одновременное завершение очередной задачи к началу следующей
Это все же про последовательность, а не про одновременность. Точки вполне могут не совпадать — между точками «дорезал лук» и «налил воду в кастрюлю» может влезть другое событие «убрать мусор со стола» или «ответить на звонок жены».
Зазор между точками «финиш 1» и «старт 2» всегда больше нуля, нужен хотя бы переход на следующий такт.

Выполнение «синхронное» постулирует обязательность завершения одного процесса до начала второго: не допускается изменение последовательности, не допускается перекрытие временных отрезков. Совпадение точек не обязательно.
Выполнение «асинхронное» разрешает перекрытие временных отрезков и даже разрешает изменение последовательности. Перекрытие — та самая «параллельность», которая в словарях является синонимом «синхронности», здесь и вижу парадокс.
Приёмы синхронизации, кстати, насильно приводят к совпадению этих точек.
Синхронизация колебаний, процессов, данных, передачи данных — очень разные задачи с разными приемами. Тут тоже забавное (возможно только для меня это забавно), должны же быть и приемы асинхронизации. В контексте темы про async/await что именно асинхронизируется?

P.S. Замечу, что я в работе использую async/await, то есть у меня не поверхностный вопрос «что вообще такое асинхронное программирование», на который уже дан ответ в данной статье и не только в ней.

P.P.S. На тему последовательности вспомнилась старая загадка: если оладья жарится одну минуту с одной стороны и еще одну минуту со второй стороны, а на сковородку помещается только две оладьи, то как за три минуты полностью пожарить три оладьи.
Зазор между точками «финиш 1» и «старт 2» всегда больше нуля, нужен хотя бы переход на следующий такт.

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

должны же быть и приемы асинхронизации

Зачастую синхронизируют именно то, что было рассинхронизировано ранее (запросы к IO, работа в других потоках/процессах). Почему нет?..

В контексте темы про async/await что именно асинхронизируется?

Напротив, синхронизируется же) Некий обработчик-continuation стремится совместить свою точку старта с завершением асинхронной операции. Начать выполняться синхронно с ее завершением.
Такая условность
Ок, отвлечемся от нуля.
Синхронный подход не требует даже примерного совпадения точек «финиш 1» и «старт 2», между ними браузер может отвлечься по множеству разных поводов. Синхронный подход предписывает только два условия: неперекрываемость, последовательность.
А асинхронный подход разрешает перекрывать и нарушать последовательность.

Синхронный рост, синхронный перевод, синхронное плавание — добиваемся параллельности, одновременности процессов.
Асинхронное выполнение — добиваемся параллельности, одновременности процессов.
Напротив, синхронизируется же)
Реализуя асинхронность мы добиваемся синхронизации… Выглядит логично в свете вышесказанного.
Придумал ответ.
Когда выбирали термин, то сыграла роль ассоциация последовательности выполнения с временной шкалой. Одномерные они похожи — есть прошлое-выполненное, настоящее-выполняемое и будущее-запланированное.
В термине «асинхронность» под «хроносом» подразумевают не временной момент, а временную шкалу. Не точка, а линия, за пределы которой нужно выйти.
между ними браузер может отвлечься по множеству разных поводов

Вы можете подтвердить это как-либо? Что между срабатыванием «прерывания» (резолва промиса любой природы) и вызовом продолжения может выполниться другой произвольный JS-обработчик. Я сильно сомневаюсь, что пользовательские хэндлеры могут иметь разный приоритет, но тратить время на поиск процедуры обработки очереди в V8 не хотелось бы.

Синхронные операции должны синхронизироваться по какому-то признаку.
Переводы — по словам, плавание — по движениям. По каким же критериям синхронизируются разнородные операции в программах, если не по моменту начала и окончания? Одна операция выражает зависимость от другой, им необходимо работать вместе, как конвейер.

Реализуя асинхронность мы добиваемся синхронизации…

Асинхронность реализует цикл событий, веб-воркеры и браузерный API, а коллбеки и промисы позволяют рулить синхронизируя весь этот цирк там, где нам это необходимо.
Вы можете подтвердить это как-либо? Что между срабатыванием «прерывания» (резолва промиса любой природы) и вызовом продолжения может выполниться другой произвольный JS-обработчик.
Мне видится какое-то разночтение.
Отвлечение браузера превратилось в выполнение JS-обработчика.
Последовательность из «завершение чистки лука» и «начало наливания воды в кастрюлю» превратилась в последовательность «срабатывание прерывания» и «вызов продолжения».
window.performance.now() - window.performance.now();
Результат — не константа, я об этом.
По каким же критериям синхронизируются разнородные операции в программах, если не по моменту начала и окончания?
Не уверен, что в случае последовательного выполнения требуются усилия по синхронизации — не вздумай выполнять все команды одновременно, сначала убедись что завершилась одна и только потом приступай к следующей…
Это асинхронность требует усилий по созданию и проверке наличия прерываний, синхронность же, под которой подразумевается просто последовательное выполнение в одном потоке, не требует усилий по прикреплению возвратов из одних функций к вызовам следующих.
Асинхронность реализует цикл событий, веб-воркеры и браузерный API, а коллбеки и промисы позволяют рулить синхронизируя этот цирк
Можно и так смотреть. Комментарием выше я описал свою точку зрения.
Результат — не константа, я об этом.

Если юзер не сможет использовать эту разницу и она не способна ему навредить, то этой условностью можно пренебречь в случае с JS.

Не уверен, что в случае последовательного выполнения требуются усилия по синхронизации

В этом случае выполнение уже синхронно настолько, что дальше некуда.

Понятия синхронный и асинхронный используются по отношению к потоку вычисления. Синхронные операции согласуются с потоком, т.е. выполняются строго последовательно, одна за другой. Для асинхронных операций синхронизация не требуется. Они могут выполняться как угодно — последовательно, параллельно, когда-нибудь или никогда — не важно.

По мне так в терминологии имеет место быть путаница. Синхронно и синхронизированно. То есть, синхронизированные операции и несихронизированные выглядело бы более логично, чем синхронные и асинхронные

У меня тупой вопрос:
Каким образом при добавлении морковки и лука мы знаем что они уже порезаны?
По куску кода явных await там нет, хотя это вроде как длительный процесс, первый кандидат на async.
Как «повар» я сразу могу начать кипятить воду, а также резать морковку и лук.
При этом когда готовы вода+морковка её можно добавить в воду и продолжать резать лук, который добавить потом, после того как морковка сварится.
Предполагается, что резка овощей реализована обычными функциями (в парадигме «повар один», т.е. основной поток выполнения JS будет у нас «поваром»), т.е. оно всё синхронно выполняется, и после вызовов chop<...>() наши овощи будут гарантировано порезаны.
Какой-то не до конца асинхронный пример получился :)
Нужно как-то ближе к реальности.
Пока резал морковку — вода уже выкипела, нужно залить новую.
Не успел порезать лук — морковка переварилась.
Чтобы резать — нужен нож и доска… и прочие прелести асинхронности

Ну на самом деле если завернуть вообще весь код из статьи в async — он не сильно пострадает от этого.

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


Wait в английском означает активное ожидание, Await что-либо — ближе к "предполагать", отложив дальнейшее рассуждения до разрешение ситуации. await в js именно так и работает, прерывая выполнение текущей функции и переключаясь на другую задачу, пока данное обещание не разрешится.

Sign up to leave a comment.

Articles