Комментарии 17
Хороший у вас пример с дирижером. Если я правильно понял, то статья для тех, кто хочет разобраться в теме. Но тогда бы упростить, может что-то отбросить, чтобы не запутать. Например, синхронное параллельное выполнение. В реальности реализация такого может иметь место для определенных кейсов, но тема не для новичков.
Можете это же описание привести на языке workflow (нотации EPC или иной). В workflow для синхронизации работы потоков введены объекты синхронизации, например, события и шлюзы. В workflowpatterns введено понятия Синхронизация (Pattern 3):
http://www.workflowpatterns.com/patterns/control/basic/wcp3.php
parallelism and pipelining patterns и т.п.
Нарисовать приведённые оркестр-алгоритмы в виде блок схем разве было бы не нагляднее (понятнее)?
В идеале описание механизмов синхронизации \ асинхронности workflow через математику:
WF2M сеть. Формализм и математика workflow
https://habr.com/ru/articles/781124/
Например, смотришь матрицу переходов (смежности) – и видишь – вот они синхронизаторы (&, Рис. 6 Пример AND-join).
Спасибо! По роду своей деятельности накопил статистику конфликта понимания данных терминов у ребят, которые впервые сталкиваются с этими темами. Почувствовал преграду в попытке объяснить эту тему, теми понятиями, которыми мы (разработчики) оперируем в рабочей речи. Отсюда и возникла потребность найти другой подход.
У меня статья почему-то ассоциируется с известным высказыванием:
"если хочешь опровергнуть какую-нибудь глупость доведи ее до абсурда".
Только я не могу понять, что же было глупостью, и не могу побороть ощющение, что до абсурда чего-то все таки не хватает.
Как по мне, стало ещё на порядок сложнее. Либо лично мне не нравятся примеры в стиле "это Алиса, она местная дурочка, а это Боб, местный эксперт-душнила", теперь думаешь о бедной Алисе, а не о задаче, и не покидает ощущения, что со мной пытаются общаться как с идиотом. Конечно сложные вещи стоит упрощать, или подбирать удачные аллегории, но без фанатизма :)
Валентин всё правильно говорит. А Алексей путает понятие асинхронности с конкретной моделью реализации асинхронных процессов async/await.
Например, в модели MPI вообще, для начала, нет никакого дирижёра.
Собственно, асинхронность A и B означает всего лишь то, что упорядоченность A и B во времени не определена. То есть, что может как A наступить раньше B, так и B раньше A. Вот и всё.
Очередные инсинуации на тему асинхронности, в которых полностью потерялся факт, что асинхронность и параллельность это два разных понятия. Зато с красочными, но в равной степени бесполезными аналогиями. И с подробной, но полностью выдуманной классификацией кейсов использования. Сколько лет должно пройти, пока такого рода графомания выйдет из моды? 10 очевидно мало.
Слишком абстрактно, если расматривать с точки зрения программиста совсем путанно.
Сначала как мне кажеться стоило бы чётко прояснить что есть однопоточный код и много поточный.
Таск это абстракция, но не над потоком, а над задачей, которая в свою очередь может выполнена и в текущем потоке.
Асинхронное выполнение тоже не говорит о том что выполнение будет передано отдельному потоку. Это термин часто путают с параллелтеым выпонением, но это не так, это два разных способа выполнения.
Про асинхронность стоит вспоминать когда задача передаёться третьей стороне, например сетевые вызовы. Запрос уходит за границы выполняемого кода, там выполняються свои обработчики и к нам приходит лишь результат.
Вроде бы похоже на параллельное выполнение, нл только потребляються ресурсы не нашего прлцесса и даже не нашего исполняющего устройства, а где то с боку по сути
На мой взгляд упрощение с дирижёрами и ничего не добавляет к понятности, а только усложняет, увеличивая число сюжетных линий.
Ровно как и попытка объяснения синхронности и асинхронности ожиданием.
Дело вовсе не в ожидании, а в возможности делать ещё одну работу, кхм, параллельно. Если у вас синхронное выполнение, вы не отдаете процессор. Держите его 'рукой'. Если же вы делаете 'sleep', процессор может заняться чем-то ещё. И это может быть вовсе не ваша программа. Понятно что все ещё сложнее и процессор переключается даже без sleep. Но тут важно не это, а то, что запущенные в асинке потоки даже если их не ждут через join, это все равно асинхронное исполнение.
Дирижёры и скрипки плохо ложатся на forkjoinpool, что явно демонстрирует их не нужность.
Спасибо. Первая статья про async, которую я понял) А некоторые умники не понимают, что создавать сложное и непонятное - просто, а писать просто и понятно - сложно.
Аналогия приведена неверно. Как и понятия об асинхронности и синхронности.
И так:
Синхронность это когда два и более действия выполняются одновременно.
Асинхронность это когда два и более действия выполняются неодновременно.
Исходя из этих определений можно понять, что нам нужно найти какие же именно действия имеются ввиду.
В синхронном программировании первое действие - ожидание, второе действие - выполнение какой-то работы на стороне.
Асинхронное программирование позволяет эти два действия выполнять асинхронно, т.е. неодновременно.
Какой же плюс выполнять эти два действия асинхронно?
Поскольку ожидание является бесполезной работой, а в качестве выполнения кода выступает поток, которому и приходится выполнять действие ожидания (т.е. простаивать), пока выполняется другое действия на стороне. То хотелось бы освободить потом, тем самым дать возможность заняться другой полезной работой, в чем из заключается плюс.
Также нужно понимать что выполнять какую-то работу на стороне может как другой поток нашего процесса, так и вовсе другой процесс.
Да, несомненно, вы правы, это элементарно и очевидно, для нас с вами. Начинающий программист увы не мыслит категориями "Поток", "Задача", для него код выполняется как текст на листке. Вываливая на него всю реальную подноготную упомянутых процессов, мы не оставляем юному коллеге шансов. Как правило приговаривая при этом - "Ну да друг, эта тема не простая, я ее тоже не с первого раза понял".
Цель статьи не в том, чтобы повторить в сотый раз прописные истины из документации. Цель в том, чтобы разоблачить конфликт понимания, конфликт с которым сталкивается джун, а не матерый программист, для которого обыденное значение терминов синхронно/асинхронно, теперь звучит не корректно. Да он слегка искажен, да он опускает из вида ряд технических моментов, это не помешает будущему специалисту, в ходе дальнейшего углубления своих навыков, дополнить и откорректировать картину.
Странно, что вы за начинающего программиста решаете как для него выполняется код.
Обычно сначала изучается тема потоков, а потом уже асинхронного программирования.
Да и вы использовали в своей статье слово "поток" 21 раз. А слово "задача" я не использовал.
Вот как раз таки из моего комментария, и понимается что на самом деле все куда проще, и термины синхронно/асинхронно звучат корректно. Не надо пытаться изменять определения этих терминов - это ошибка.
Если я прав, то вы пробовали именно такими словами как я объяснить начинающим? В чем именно вы увидели их не понимание?
Семантические ловушки асинхронности: Ключи к разгадке и эффективному освоению тем Task, Синхронность, Асинхронность