async/await

[ex0_planet]

Подумалось внезапно - а в какой момент и почему так получилось, что практически все современные языки пришли к промисам и сабжу для записи параллельного кода? До этого момента какие только извращения не бытовали: конечные автоматы, файберы, green threads (включая чудо нанотехнологий поверх duff device под названием protothreads), просто ад

Comments

[eddy_em]

Мне, как сишнику, это - как тарабарщина какая-то ☺
Параллельный код - это либо fork, либо pthreads вручную, либо pthreads "автоматом" - openmp.
Неужто появились какие-то новомодные способы? У меня коллега - плюсовик, пишет исключительно на самой последней ревизии крестов (говорит, там много чего "вкусного"). Но тоже параллельный код делает аналогично. Ну, или через обертки вроде ASIO. Но у тех тоже "под капотом" pthreads (а иногда даже блокирующая псевдопараллельность через поллинг).
UPD: погуглил. Оказывается, это про жабоскрипт. Премерзский язычонок. Очень хреново, что в веб-мордах без него никуда. Хуже жабоскрипта может быть разве что пытхон какой-нибудь или вантузоидный до-диез (но там вообще маразм высшей стадии).

[ex0_planet]

Плохо гуглил. Почти все языки последнего десятилетия это поддерживают.

Смысл в замене конечно-автоматной похабщины кодом в обычном линейном стиле: "if this do_that(); and_do_that(); and_then_do_another_thing();".

[eddy_em]

Ну, ХЗ. Я всякое говно вроде пытхонов/ржавчин и т.п. новомодной хипстерской фигни, которая через несколько лет обратно в Лету канет, не принимаю во внимание. Но вот помимо С иной раз необходимость возникает в кресты нос сунуть, а то и жабоскриптом обляпаться - если веб-морда нужна.

> Смысл в замене конечно-автоматной похабщины
А вот знакомый-крестовик, наоборот, конечные автоматы использовать стал, т.к. это охрененно удобно! Правда, не в сишном стиле (switch/case), а в виде методов класса или как-то так (после красивого страуструповского С++ современные кресты я вообще не воспринимаю).
Там еще всякую дичь можно делать вроде run().first().second().third()... В принципе, я и в сях так могу заморочиться со структурами с указателями на функции, но нафиг оно мне нужно, когда есть более красивые варианты?
А уж для микроконтроллеров конечные автоматы - вообще прелесть! У меня бывают всякие вложенные по нескольку уровней. Да и в последнем велосипеде для управления спектрографом у меня все на автоматах.

[ex0_planet]

> А уж для микроконтроллеров конечные автоматы - вообще прелесть! У меня бывают всякие вложенные по нескольку уровней.

Любишь, поди, в дебаггере сидеть? :) Переписать это хотя бы на green threads, сразу жизнь в несколько раз проще станет.

[mbr]

Ну да. Нюанс в том, что даже для FSM нужны async/wait.

[ex0_planet]

Нет, зачем. Для

switch(state) {
case 0: do_this(); nextstate = 1; break;
case 1: do_that(); nextstate = 2; break;
....
}
return nextstate;

никакие дополнительные возможности не нужны, наоборот, поверх этого можно реализовать всё что угодно. Только неудобно.

[mbr]

это в идеальном мире. В реальности плодить дополнительные состояния ради гарантированно быстрых ответов от другого процесса смысла нет, проще и подождать.

[ex0_planet]

Тогда придется "плодить" вытесняющую многозадачность.

[ext_122116]

Ну я тут сейчас немного упарываюсь по университетскому опенсорсу, так что могу предположить следующее - практически одновременно в разработку "промышленных" ЯП попали несколько "выпускников" одного из этих направлений - так что надо смотреть, за что топили в Университете Калифорнии двадцать лет назад :)

[balmerdx]

И как async/await спасает от доступа к данным из нескольких потоков?

[ex0_planet]

Так, что к данным доступаются из единственного потока, если ты так ставишь вопрос.

[balmerdx]

Из одного потока - это как? Вот предположим есть у нас очень большой hash_map, ну скажем на 20 Гигабайт (чтобы не было желания его скопировать несколько раз по потокам). Предположим, что мы хотим получить к нему доступ из нескольких потоков на чтение/запись. Как в этом случае поможет async/await ?

И да - отлично понимаю, как может async/await помочь в случае, если надо послать по сети запрос, а дождаться получения и вернуть результат в основной поток. Шутка юмора в том, что используя действительно асинхронные интерфейсы можно добиться значительно более высокой производительности, не потеряв в удобстве кода.

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

[ex0_planet]

Я не понимаю что ты пытаешься доказать. Async/await - просто способ записывать асинхронный код с синтаксисом, похожим на обычный синхронный. Точка.

Многопоточные проблемы имеют к этому весьма косвенное отношение.

[vanxant]

практически все современные языки пришли к промисам и сабжу для записи параллельного кода

Почему параллельного-то? Асинхронного, да, но часто однопоточного.

[ex0_planet]

My bad, надо было concurrent написать, но мне зачем-то захотелось подобрать русскоязычный аналог.