метода. Он не блокируется, а при окончании выполнения вернется в тредпул
Основной поток продолжит выполняться - выведет строку, а потом будет ждать, пока поток из тредпула сообщит о том, что он закончил.
И вопрос в том, что чем отличается заблокированный поток, от ожидающего потока?
Я пытаюсь разобраться именно в том, что дает асинхронность такого, что она почти повсеместная.
Мое предположение такое:
1) неблокирующие вызовы IO
2) мелкомодульный параллелизм для CPU
Типа если я в async методе GetByIdAsync() юзаю await _dbContext.FindAsync(), а потом в контроллере юзаю var user = await _userRepository.GetByIdAsync() то на каждом "слое" мои потоки незаблокированы.
для ASP основной поток - принятие запросов от юзеров и передача их обработки, следовательно не будет момента, что у меня все потоки заблокированы, потому что они ждут ответа от БД. Достигается это тем, что на каждом "слое" поток берется из тредпула, выполняет код до точки await и возвращается в тредпул тем самым позволяя основному потоку дать ему другую работу. И так до внутренней реализации запроса к бд, в котором юзается какой-то коллбэк. Как только закончила БД свою работу она говорит, что я закончила забирайте результат. На этом этапе опять таки берется поток из тредпула и результат прокидывается через все "слои" и продолжается обработка запроса дальше.
Я прав?
что то много написано async - await не создаёт потоков, не перебрасывает никакую работу на другие потоки, это просто синтаксический сахар вокруг тасков. Нативные асинхронные операции IO работают через келбек, вызывается метод Do и возвращается управление вызывающему коду, но сами данные просто уходят в какой то внутренний буфер ОС или устройства, потом, когда операция действительно завершается устройство оповещает ОС об этом, в .net есть специальный пул потоков для того, чтобы обслуживать IO операции, вот оттуда берётся поток и завершает таск и остальной код.
ключевая часть неблокирующего вызова в вызывается метод и возвращается управление
Обсуждают сегодня