Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 12
"во-первых нет, в Go нет асинхронности, во-вторых нужна синхронизация"
Интересно, что было в голове у составителя ответа? Если нет асинхронности, то значит все синхронно и в таком случае никакая дополнительная синхронизация нигде не нужна. :)
Да вроде есть, если определять ее как "переключение между лёгкими задачами без блокировки OS потоков"
Я бы асинхронность определил как выполнение задач независимо друг от друга. А уж в разных потоках эти задачи, или в одном, не имеет никакого значения, главное, что порядок завершения задач не гарантирован.
Асинхронность в первую очередь про освобождение системных ресурсов при ожидании ответа.
А как результат эта внутренняя кооперативная многозадачность даёт лёгкость в переключении, позволяющая M*N - M зелёных задач на N системных потоков, переключение в user space по await-точкам, без вытеснения.
Если к функциям дописать ключевое слово go, они будут работать асинхронно?
Как рантайм решит
То есть при возврате может сменить системный поток, а может и остаться на старом. Но дебагеру это всё равно, он работает прозрачно
Зачем вообще отделять асинхронность от параллельности? Параллельность просто является частным случаем асинхронности, когда независимые задачи выполняются параллельно. И всё равно они выполняются асинхронно.
в мире высокого уровня может и так, но асинхронность и параллельность это разное.
Например классический RTOS - асинхронность можно строить даже на одноядерном процессоре. Но вот параллельность только если используются разные вычислительные ядра и на низком уровне нужно будет руками нарезать и раскидывать задачу что бы она параллельно выполнялась в разных потоках
Асинхронность предполагает точку синхронизации (когда можно продолжить исполнение след. куска подзадачи - пресловутые await), если нет синхронизации, то её нет. Разрыв исполнения подзадачи должен быть, чтобы назвать её асинхронной. Параллельность - про исполнение подзадач одновременно. Без синхронизации в ней не будет асинхронности, т.к. не будет логического разрыва исполнения.
Есть ещё синхронная параллельность в виде SIMD и ILP, например. Или стрельба через винт как механическая аналогия.
а потом приходит Эндрю Келли, выдает спич про асинхронность через I/O интерфейсы, и выносит окрашивание асинка на свалку истории.
Асинхронность
Метод выполнения задач, при котором IO bound операции не блокируют основной поток. Иными словами в современном мире это просто выполнение задач в корутинах/горутинах/виртуальных потоках.
Мне кажеться Вы сами запутались.
Асинхронность - это свойство частей исполняемого кода работать не последовательно. Например, у нас есть задача A, для ее вычисления нам нужно еще вычислить задачи B и C. Если мы вычисляем их последовательно: A1->B->C->A2 то получаем синхронно выполненный набор задач. Если же мы ломаем последовательность вычислений, продолжая вычислять работу которая должна быть после B и C еще не имея результатов тех самых B и C , то получаем непоследовательно, ну или не синхронно ну или асинхронно выполненную последовательность.
Причем здесь IO bound задачи в определении асинхронности? Я с тем же успехом могу асинхронно считать алгоритмы в разных потоках выполняя работу параллельно или не параллельно в одном, и так и так работа будет асинхронной.
Как выполнять работу: на той же машине или на другой, с одном потоке или нескольких, на корутинах или потоках ОС, блокировать или не блокировать дополнительный поток - это все уже детали. Единственно важное свойство - это возможность текущему потоку управления не блокироваться в ожидании другой задачи в определенных точках. Это и есть асинхронное выполнение.
Если все же немного выглянуть из мира пайтона, то базовый пример асинхронности - аппаратные прерывания. Выше уровнем - разные софтверные прерывания, сигналы и коллбэки со стороны операционки. Еще выше, использование операционкиных сисколлов со стороны пользовательских программ. Вот так например я могу вызвать у себя асинхронную запись буфера:
sys$qio(EFN$C_ENF, chan, IO$_WRITEVBLK, &iosb, 0, 0, buf, buf_size);
Причем вместо 0, 0, можно указать что-то типа my_ast, magic_number и тогда по завершению записи функция my_ast получит Asynchronous System Trap со стороны системы.
И только потом уже начинается синтаксический питоновский сахар.
С потоками тоже все чуточку сложнее. Изначально все эти позикс треды часто работали на пользовательском уровне. И только сейчас, по мере забвения древних нормальных юниксов, все привыкли что шедулинг тредов выполняется где-то в ядре с расходами на переключение контекста.
Соответственно есть в позиксе функция pthread_attr_setscope предназначеная для выбора между System Contention Scope или Process Contention Scope треда. и т.д.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Меня раздражает, как объясняют асинхронность