Асинхронность
Запись от Pure размещена 02.09.2013 в 02:18
Показов 2268
Комментарии 5
|
Она нынче в моде. Еще не так давно кто то благоговел пред словом многопоточность, а теперь интернеты пестрят словом асинхронность. Я лично в контексте чтения инфы про веб сервера часто видел. Попробую изложить своё видение асинхронности и ожидаю комментов опытных разработчиков-практиков, которые как всегда помогут взглянуть на тему более комплексно. Итак в своем повествовании я буду использовать следующее инфо. 1. собственный опыт работы с контроллерами 2. чтиво книг дяди Рихтера про вин32, язык Python 3. инфо из инета Начнем с 3-го, все верещат о некой событийно ориентированной модели веб сервера, способной выдержать проблему 10000 соединений. Мол фишка в том что время процека расходуется весьма рационально он не ждет потоков которые залочены в ожидании, он обрабатывает некую очередь с событиями, в которую события добавляются "сами чудесным образом". Поскольку веб сервер это мощь и красота включающая в себя несколько видов IO - это хороший объект для попытки понять что э такое асинхрон. Спускаемся на пункт ниже. 2. дядя Рихтер. В своей книге он четко расписывает все режимы, характерные для винды. То бишь есть блокирующее соединение с сокетом или чтение файла и мы выделяем сию операцию в отдельный поток, что оно было параллельно. Это как раз тот расклад где теряется время проца. Рихтер описывает иную модель. ТУ САМУЮ. когда бы отдаем на откуп ОС виндовс операции ввода-вывода, касаемо файлов или сетевого взаимодействия. То бишь мы не создаем потоков "вручную", это за нас делает ОС. На мой взгляд эта концепция бросится в глаза тем кто будет учить питон.Это метафора. Лутц советует все переложить на интрепретатор потому как он выполняет все со скоростью прог на С, а питон на скорости питона. То бишь концепт - переложить все на более быструю реализацию, не брать ручное управление на себя. Меньше циклов на питоне, больше юзать встроенное на С в интерпретатор. То же самое и Рихтер. Наиболее эффективно - отдать оси самой балансировать нагрузку и дергать колбаки. На нас ляжет лишь описание высокой логики, все остальное делает ОС, она там создает пул потоков по колву ядер в случае с IOC PORT, сама отлавливает окончание момента обработки - сама делает следующий шаг в обработке очереди. В первом приближении может показаться - ЧТО ЭТО ЗА ХЕРНЯ. С какого хрена она должна работать быстрее. Идем ниже. 1. занимаясь микроконтроллерами становится примерно ясно как оно все устроено и почему так получается что асинхрон рулит. Контроллеры позволят увидеть самый низ. Итак есть 2 варианта. Например у на есть флэш память, UART и центральный проц - для простоты. Нам надо записать массив инфы во флэш. У флэшки есть собственный контроллер - управляющей ее работой. И вот мы решили использовать синхрон. Мы знаем что когда запись во флэш закончится - то в определенном регистре контроллера флэш будет поднят флаг. И вот мы запустили запись и циклимся проверяя флаг - все замерло. Флаг поднят, отскочили из цикла пошли далее. Узнаваемо? Вполне.Но есть и иной вариант. Мы начинаем использовать механизм прерываний.Он насколько я понял аппаратен. Мы запустили запись во флэш и спокойно себе делаем что то еще, например пишем в УАРТ хэллоу ворд. То бишь управление вернулась и проц делает полезную пользу. Вот во флэш закончилась запись - ее контроллер генерирует прерывание, вот тут то и прерывается основной цикл. При этом дергается коллбак который мы прописали в тектсе программы, он отрабатывает и код пошел дальше. Что мы имеем? В таком режиме мы отдали управление ЖЕЛЕЗУ, проц не занимался контролем исполнения, мы делали полезную работу - именно ту, которую полезно делать процу. То бишь меньше коддинга, доверьтесь железу и получите удовольствие. Поскольку ОС это всего лишь программа обслуживающая железо, на мой взгляд она действует именно так, и предоставляет еще это API для нас, чтоб мы его попользовали. То есть уж чтоб не совсем в железках ковыряться. На этом на мой взгляд и строится весь тот самый асинхрон. Программа СЕРВЕР использует соответствующее API соответствующей ОС, для передачи управление через ОС, на железо. Когда срабатывают прерывания от котроллеров жестких дисков, сетевух серверного оборудования, серверная ОС наполняет очередь соответствующими событиями, которые и обрабатывает проц, рационально используя время. Вот таки так я это вижу. Буду рад каким либо дополняющим комментам. Ну либо иной версии того, "КАК ВСЕ РАБОТАЕТ" |
Размещено в Без категории
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Всего комментариев 5
Комментарии
-
А почему интернеты пестрят им только теперь?Запись от Vourhey размещена 02.09.2013 в 10:45 
-
Я бы хотел увидеть твой собственный ответ на твой же вопрос. Какой твой вариант?Запись от Pure размещена 02.09.2013 в 13:10
-
Школота дошла до следующей главы в книге?
Запись от Vourhey размещена 02.09.2013 в 13:36
-
"Игорь Сысоев начал разработку в 2002-м году[6]. Осенью 2004 года вышел первый публично доступный релиз. По состоянию на 2013 год, поддержка и доработка nginx продолжается."
"Node разработал Райан Дал (англ. Ryan Dahl) в 2009 году после двух лет экспериментирования над созданием серверных веб-компонентов. В ходе своих исследований он пришел к выводу, что, вместо традиционной модели параллелизма на основе потоков, следует обратиться к событийно-ориентированным системам. Эта модель была выбрана из-за простоты, низких накладных расходов (по сравнению с идеологией «один поток на каждое соединение») и быстродействия. Целью Node является предложить «простой способ построения масштабируемых сетевых серверов»."
думаю ты правЗапись от Pure размещена 02.09.2013 в 23:36
-
событийная модель, модель акторов - все и всяЗапись от alex_x_x размещена 10.09.2013 в 05:29
