Знай я, что слово "асинхронный" вызовет такое непопадание в смысл, просто не стал бы его использовать... И несмотря на то, что я попытался определить термины в следующем посте, всё равно появляются комментарии про то, что я "путаю две вещи" и "асинхронность и multicore ортогональны". Постараюсь обясниться яснее и короче.
Повторюсь цитатой из предыдущего поста:
Ещё один термин, которому не повезло — асинхронность. По-настоящему она означает вызов функции, которая не делает всей своей работы сразу, а быстро возвращает управление в вызвавшую программу, выполняя свои вычисления параллельно с ней. Никакого конкретного способа реализации такого параллелизма не предполагается.
Однако часто "асинхронность" неявно жёстко привязывают конкретно к асинхронному вводу-выводу, когда асинхронность вызова обеспечивается тем, что долгую и тупую часть операции по перекладке байтов на себя берёт отдельный сервис ядра. Чтобы отличать это понятие от "асинхронности вообще", я буду пользоваться тремином неблокирующий IO.
Уважамые комментаторы! Я не писал пост про асинхронный I/O. Этот вопрос вполне себе решён библиотеками уже сейчас, и проблем не вызывает. Я писал про асинхронное всё остальное, чего у нас ещё нет. Про распараллеливание любых алгоритмов: начиная от элементарной сортировки и до алгоритма поведения игрового мира с сотнями юнитов. Я не хочу спорить про правомерность употребления слова "асинхронность" в этом контексте. Если оно вам не нравится, просто используйте слово "параллельность". Или "concurrency".
Но только не пишите мне про ввод-вывод, пожалуйста :-)
Комментарии: 18
Иван, но ведь и в фокусе с yield и в node.js весь код программы исполняется по прежнему строго в один поток. Это — физически —именно асинхронность (не-синхронность с системными вызовами), но не параллелизм.
Во-первых надо уточнить, что фокус с yield не связан напрямую с темой про глобальный параллелизм. Это просто мысль в голову пришла.
Во-вторых, асинхронность всегда означает параллелизм. Даже если это I/O. При асинхронном I/O основной код программы исполняется в один поток, но I/O-то идёт с ней параллельно. То, что это происходит не в ещё одном треде — это просто удачная деталь реализации. Но повторюсь, это не то, о чём я проповедую :-)
асинхронность часто подразумевает событийность, возможно термин event-driven будет к месте и более понятен.
offtopic заметил тренд в блоге "провоцирующие " посты, которые вызывают интересные комментарии, этакий провоцирующий data mining :-) Жаль, что работает только с умными подписчиками. Очень интересно, жду продолжений на другие темы. ;-)
Я согласен с ddenis. Асинхронность не всегда означает параллелизм. Асинхронность с успехом используют с тех времен когда SMP не существовало в принципе. Более того, верно и обратное - не все формы параллелизма сводятся к асинхронности. Вот сведите мне пожалуйста SIMD параллелизм к асинхронности.
Ну да ладно... Скажем так, если копать достаточно "глубоко", то в конечном счете почти все формы параллелизма можно свести к асинхронности. Но в этом то и проблема. Настолько много вы прячете за одним словом, что непонятно что же вы в конце концов имеете ввиду. Из всех ваших трех заметок, я понял (возможно, опять неверно) только то, что вы за кооперативную многозадачность. С этой четко сформулированной мыслью я лично абсолютно согласен. А что вы имели ввиду под асинхронностью непонятно.
В первой заметке вы привели в пример С + GCD и Erlang. В этих двух языках принципиально разные модели обеспечения конкурентного исполнения: erlang - модель actor'ов, GCD тупой thread pool дополненный syntax sugar для удобства работы. В моем понимании ничего общего между ними не существует.
Давайте более конкретно, что ли. Напишите заметку, в которой приведите примеры кода нескольких систем или библиотек (желательно не только python, его мы уже видели :) ) параллелизм в которых основывается на асинхронности с вашей точки зрения. Я думаю, так разговор будет идти в более продуктивном русле, и лично я быстрее пойму какую именно форму параллелизма вы имели ввиду под асинхронностью.
А иначе это все из разряда "из пустого в порожнее"...
Позвольте немного перефразирую ваше определение асинхронности. Мне кажется у меня получится несколько более утрировано, но лучше отражающе суть понятия.
Асинхронность означает то, что указанное действие будет где-нибудь, как-нибудь, когда-нибудь выполнено.
И рядом для синхронности:
Синхронность означается то, что указанное действие будет выполнено так, что бы выполнились вот эти вот условия (место вызова, тот же неблокирующий ввод/вывод...)
Ваня, извини, но про ввод-вывод напишу. Дисковый и sendfile он до сих пор плохо-асинхронный. Т.е. если с сетевыми сокетами вопрос худо-бедно решен, то с диском ещё нет.
Теперь насчет коллбеков и прочего. Я с тобой полностью несогласен. Я последние полгода работаю больше с EventMachine, чем с рельсами и могу сказать, что это очень, очень, невообразимо неудобно, особенно по сравнению с эрлангом. На каждый чих вместо content = http.get("http://ya.ru") писать http.get("http://ya.ru", :onresult =>