На 10:55 идет речь о суффиксе Async для асинхронных методов. Раньше действительно такая рекомендация встречалась в msdn, но сейчас уже почти все асинхронное и скорее нужен суффикс Sync )) Так что лучше это решать на уровне договоренности по стилю кода в команде
21:35 - мы ничего не ждём. Прекрасно, тогда зачем await для операции, которую запустил - забыл? Чтобы впустую потратить время на переключение контекста, дождавшись результата, ничего не сделать и вернуть поток обратно в пул?
Сложные расчеты, которые нагружают ЦП, они самые CPU Bounds, лучше не асинхронно выполнять, а в других потоках. Так быстрее будет, ведь асинхронный код != многопоточность или многозадачность. И обычно, во всяких приложениях с UI или игровых движках всё выполняется в одном потоке, то есть асинхронный код будет выполняться в одном и том же потоке, можешь проверить, например, в Windows Forms или WPF, или на движке Unity.
Здравствуйте. Подскажите по таймингу 14:37 . public class HomeController : Controller { private readonly BookRepository bookRepository; public HomeController ( BookRepository bookRepository) { this.bookRepository = bookRepository; } } В чем разница между приватной переменной bookRepository и той что создается в конструкторе public HomeController ( BookRepository bookRepository) ? Ведь типа у них одинаковые , следовательно и приватная переменная должна иметь доступ к репзиторию, ?
Этот подход называется Dependency Injection (Внедрение зависимостей). Погуглите, это больше концептуальный подход, чем технический. Так проще поддерживать код, тут просто пример очень простой в видео, поэтому BookRepository можно и явно объявить. Но так лучше не делать в реальных программах.
Добрый день. Есть вопрос по изображению с асинхронной схемой. Есть пул потоков, в котором два потока. Поступил запрос на сервер и занял один из потоков. На время операции с БД этот поток возвращается в пул потоков. Но ведь для выполнения асинхронной операции с БД тоже нужен выделенный поток. Он находится не в том же пуле потоков? или пул потоков для обработки запросов веб-приложения и пул потоков доступных процессу это разные вещи?
да, вы правы. Освобождается поток, который вызвал асинхронный метод, а для выполнения вызванного метода берется поток из thread pool, автор напутал по всей видимости
@@sandback122то есть ожидание или запрос будет обрабатывать другой свободный поток из пула потоков? А наш главный поток освободится для других задач нашей программы? И как тот поток получит результат, планировщик задач оповестит наш главный поток, чтобы он вернулся к тому методу и продолжил выполнение?
А разве можно сделать асинхронно вначале получить из базы данные, долго пересчитывать на основе условий пришедших в запросе от юзера, а потом сохранить результат в базу.. Всё это долгие операции, но их невозможно запустить асинхронно! Получается, что их все три нужно вынести в отдельную функцию и уже именно её выполнять асинхронно? А тогда какой смысл делать её асинхронной, всё равно выполнения всех операций только последовательно (синхронно)?
Очень крутое видео и в принципе помогло решить кучу вопросов) знаю что ответ можно ждать долго, но всё же есть вопрос, если созданы асинхронные методы, в синхронных больше нет нужды в проекте?
Не совсем понятно как это происходит на низком уровне. Клиент переходит по ссылке, ему в этот момент выделяется поток. Мы переделываем методы на async, что в свою очередь заставляет поток вернуться обратно в пул. Но как тогда клиент остается в зависшем состоянии, пока await не вернется?
Когда асинхронная операция выполнется долгое время и поток который начал выполнение ушел на другие задачи, кто и как сообщает о том, что длительная операция завершилась и ее нужно обработать, как это происходит?
Это всё довольно просто. А как быть, если выполняемое действие настолько долгое, что я хочу при поступлении запроса запустить длительное действие и сразу вернуть код 204, чтобы клиент не ждал. Проблема в том, что в этом случае то самое длительное действие почему-то перестаёт работать. В моём случае это экспорт видео специальной библиотекой в файловую систему. В этом случае как быть??
@@АлександрБабаев-п2й Тут не важен фреймворк. Сам подход автор подсказывает абсолютно верный. Фоновые задачи можно реализовать хоть на таблице SQL и ее постоянном чтении с выгребанием этих задач, хоть на шине событий (что я считаю более правильным). Продолжать выполнение пользовательского потока уже после того, как будет возвращен ответ в корне неверно, такие реализации часто приводят к переполнению памяти, чрезмерной нагрузке по CPU на сервере с приложением и т.п. Ну и вообще подход в целом не очевидный.
Есть минусы у асинхронного выполнения? Ну т.е. почему тогда бы не писать вообще все асинхронно, я достаточно редко встречаю именно такое решение. Звучит так, будто это панацея и нужно постоянно это использовать.
Само по себе асинхронное программирование отбирает много мощности машины, в сравнении с обычными методами, поэтому нужно понимать, когда необходимо использовать асин/авейт, потому что под капотом это создание нового потока (или даже процесса). К примеру - если у тебя есть кусок кода, где одно зависит от другого (получаешь из базы данных какую-то информацию, потом делаешь какие-то действия над данными и потом возвращаешь обратно), там асинхронка не будет нужна, потому что сначала нужно получить данные, а только потом делать какие-либо манипуляции, а вот если у тебя есть код, в котором нужно как можно быстрее что-то сделать и при этом ничего друг от друга не зависит (например - разные запросы в БД, то там можно создавать таски и уже асинхронно делать все это)
@@Dinarqka Условно, если я прошу от БД какие -то данные без обработки, сразу выдавая их в исходном виде юзеру, то там лучше асинхронное? Вроде понял, спасибо
@@hysapod ну вот если нужно, например, вернуть юзеру результат десяти обычных запросов , то да, юзеру не придется ждать, пока они выполнятся последовательно, он просто будет получать по мере выполнения тасок
есть ещё пара важных моментов: мы возвращаем основной поток, который натыкается на await, обратно в пул. Окей. Но саму операцию-то кто выполняет при этом, которая завёрнута в конечный автомат? Background поток или китайцы педали крутят? Почему-то ни слова об этом не услышал, равно как про ConfigureAwait. Всё самое интересное так и осталось за кадром
Доброго дня. Как вы хотите за 20 мин многопоточность и асинхронность рассказать. Для типовых решений вполне достаточно. Книги почитайте или консультации.
@@alekseev74 да вообще не камень в Ваш огород, спасибо за видео, просто не услышал того, что хотел для себя услышать) По многопоточности видео должно быть вообще на несколько часов, понятное дело)
@@MrAquirier Все ок) Смысл видео в том, что в asp.net чаще всего (не всегда) пиши async/await, ну и как это в entity framework реализовано. Кстати с момента записи видео .net core и ef core уже хорошо развились, работать одно удовольствие.
Операционная система выполняет операцию, ей доступно очень много потоков процессора, она там стоит в очереди на обработку, по-моему так, когда получает результат, то планировщик задач оповещает главный поток, который запустил наш асинхронный метод, вернутся и продолжить код в том методе
Семен, ваша серия роликов по созданию MVC приложения всё еще актуальна? В целом. Просто даже мало иностранных контент-мейкеров делают такие обучающие видео. Разве что tutorialsEU.
Огромное спасибо вам за уроки ASP Core, стал лучше понимать! Очень жду новых!
Спасибо большое за ваши ролики всё очень доступно и понятно! С нетерпением жду новых роликов!
Спасибо за труд, единственный урок где действительно стало понятно как работает асинхронка.
Наконец-то пришло понимание асинхронности. Спасибо огромное за урок!
На 10:55 идет речь о суффиксе Async для асинхронных методов. Раньше действительно такая рекомендация встречалась в msdn, но сейчас уже почти все асинхронное и скорее нужен суффикс Sync ))
Так что лучше это решать на уровне договоренности по стилю кода в команде
Спасибо за доступный видеоурок!
Все очень понятно. Спасибо.
21:35 - мы ничего не ждём. Прекрасно, тогда зачем await для операции, которую запустил - забыл? Чтобы впустую потратить время на переключение контекста, дождавшись результата, ничего не сделать и вернуть поток обратно в пул?
Отличная работа, наконец то прочувствовал с более глубоким пониманием работу этих операторов. Подписался
Семен, Спасибо! Все четко и ясно.
Огромное спасибо за видео, наконец-то дошло то, что так часто спрашивают на собеседованиях. Стал чуть умнее :)
сделай пожалуйста видео по "Dependency injection"
Блин чувак асинхроность это необязательно новый поток ))
Огонь!
Очень хорошее объяснение, спасибо!
отлично объясняешь , было бы круто послушать твое объяснение разницы между многопоточностью и асинхронностью
Очень круто, спасибо
Спасибо за труд. Было очень интересно послушать начинающему.
шик, спасибо
То, что нужно. Спасибо.
Определенно лучшее объяснение из тех, что я видела. Для новичков - идеально!
Сложные расчеты, которые нагружают ЦП, они самые CPU Bounds, лучше не асинхронно выполнять, а в других потоках. Так быстрее будет, ведь асинхронный код != многопоточность или многозадачность. И обычно, во всяких приложениях с UI или игровых движках всё выполняется в одном потоке, то есть асинхронный код будет выполняться в одном и том же потоке, можешь проверить, например, в Windows Forms или WPF, или на движке Unity.
У класса таск есть удобный статический метод Run, который выделяет ОТДЕЛЬНЫЙ поток для метода, который мы передаем Task.Run(() => );
Стесняюсь спросить. Вопрос может и не совсем по теме. Зачем на 14:44 минуте создаем конструктор для HomeController?
Почитайте про тему "Внедрение зависимостей (Dependency Injection). Здесь просто код слишком простой.
@@alekseev74 Спасибо 🙏 Прочту
спасибо большое
Все класно и доходчиво расказано. Можеш сделать видео по многопоточности?
Здравствуйте. Подскажите по таймингу 14:37 .
public class HomeController : Controller
{
private readonly BookRepository bookRepository;
public HomeController ( BookRepository bookRepository)
{ this.bookRepository = bookRepository; }
}
В чем разница между приватной переменной bookRepository и той что создается в конструкторе public HomeController ( BookRepository bookRepository) ? Ведь типа у них одинаковые , следовательно и приватная переменная должна иметь доступ к репзиторию, ?
Этот подход называется Dependency Injection (Внедрение зависимостей). Погуглите, это больше концептуальный подход, чем технический. Так проще поддерживать код, тут просто пример очень простой в видео, поэтому BookRepository можно и явно объявить. Но так лучше не делать в реальных программах.
@@alekseev74 Понял, спасибо большое за ответ и за ваши труды, щас почитаю.
Спасибо!
как вас найти в соц. сетях?
Спасибо большое ! А почему используется Таск всегда с async? Разве это обязательно?
Добрый день.
Есть вопрос по изображению с асинхронной схемой.
Есть пул потоков, в котором два потока.
Поступил запрос на сервер и занял один из потоков.
На время операции с БД этот поток возвращается в пул потоков.
Но ведь для выполнения асинхронной операции с БД тоже нужен выделенный поток.
Он находится не в том же пуле потоков? или пул потоков для обработки запросов веб-приложения и пул потоков доступных процессу это разные вещи?
да, вы правы. Освобождается поток, который вызвал асинхронный метод, а для выполнения вызванного метода берется поток из thread pool, автор напутал по всей видимости
@@sandback122то есть ожидание или запрос будет обрабатывать другой свободный поток из пула потоков? А наш главный поток освободится для других задач нашей программы? И как тот поток получит результат, планировщик задач оповестит наш главный поток, чтобы он вернулся к тому методу и продолжил выполнение?
Спасибо.
Кайф, просто и доступно, благодарю.
А разве можно сделать асинхронно вначале получить из базы данные, долго пересчитывать на основе условий пришедших в запросе от юзера, а потом сохранить результат в базу.. Всё это долгие операции, но их невозможно запустить асинхронно!
Получается, что их все три нужно вынести в отдельную функцию и уже именно её выполнять асинхронно? А тогда какой смысл делать её асинхронной, всё равно выполнения всех операций только последовательно (синхронно)?
Вы же говорили, что не стоит делать методы возвращающие void асинхронными а в контроллере сделали
А когда новые видео?
А конечный автомат = машина состояний?
Очень крутое видео и в принципе помогло решить кучу вопросов) знаю что ответ можно ждать долго, но всё же есть вопрос, если созданы асинхронные методы, в синхронных больше нет нужды в проекте?
Если это не запросы или ожидания, то да
Не совсем понятно как это происходит на низком уровне. Клиент переходит по ссылке, ему в этот момент выделяется поток. Мы переделываем методы на async, что в свою очередь заставляет поток вернуться обратно в пул. Но как тогда клиент остается в зависшем состоянии, пока await не вернется?
Доброго дня. Да цели не стояло глубоко в вопрос залезть, максимально практично показал. Погуглите про брокеры сообщений типа RabbitMQ и т.д.
Относительно темы async/await вопросов нет, спасибо, все достаточно понятно. Будем гуглить.
@@snake-- Про потоки - это уже вопрос архитектуры всей системы, не только морды в виде сайта.
Когда асинхронная операция выполнется долгое время и поток который начал выполнение ушел на другие задачи, кто и как сообщает о том, что длительная операция завершилась и ее нужно обработать, как это происходит?
Планировщик задач отвечает, когда вернутся в этому методу
Очень понятно!
Это всё довольно просто. А как быть, если выполняемое действие настолько долгое, что я хочу при поступлении запроса запустить длительное действие и сразу вернуть код 204, чтобы клиент не ждал. Проблема в том, что в этом случае то самое длительное действие почему-то перестаёт работать. В моём случае это экспорт видео специальной библиотекой в файловую систему. В этом случае как быть??
Как вариант можно запускать такие задачи как процессы в фоновом режиме. Погуглите про "asp.net core background task".
@@alekseev74 Возможно, в Core с этим нет проблем, но мне надо это сделать в ASP.NET версия фреймворка 4.8
@@АлександрБабаев-п2й Тут не важен фреймворк. Сам подход автор подсказывает абсолютно верный. Фоновые задачи можно реализовать хоть на таблице SQL и ее постоянном чтении с выгребанием этих задач, хоть на шине событий (что я считаю более правильным). Продолжать выполнение пользовательского потока уже после того, как будет возвращен ответ в корне неверно, такие реализации часто приводят к переполнению памяти, чрезмерной нагрузке по CPU на сервере с приложением и т.п. Ну и вообще подход в целом не очевидный.
Есть минусы у асинхронного выполнения? Ну т.е. почему тогда бы не писать вообще все асинхронно, я достаточно редко встречаю именно такое решение. Звучит так, будто это панацея и нужно постоянно это использовать.
Само по себе асинхронное программирование отбирает много мощности машины, в сравнении с обычными методами, поэтому нужно понимать, когда необходимо использовать асин/авейт, потому что под капотом это создание нового потока (или даже процесса).
К примеру - если у тебя есть кусок кода, где одно зависит от другого (получаешь из базы данных какую-то информацию, потом делаешь какие-то действия над данными и потом возвращаешь обратно), там асинхронка не будет нужна, потому что сначала нужно получить данные, а только потом делать какие-либо манипуляции, а вот если у тебя есть код, в котором нужно как можно быстрее что-то сделать и при этом ничего друг от друга не зависит (например - разные запросы в БД, то там можно создавать таски и уже асинхронно делать все это)
@@Dinarqka Условно, если я прошу от БД какие -то данные без обработки, сразу выдавая их в исходном виде юзеру, то там лучше асинхронное?
Вроде понял, спасибо
@@hysapod ну вот если нужно, например, вернуть юзеру результат десяти обычных запросов , то да, юзеру не придется ждать, пока они выполнятся последовательно, он просто будет получать по мере выполнения тасок
есть ещё пара важных моментов: мы возвращаем основной поток, который натыкается на await, обратно в пул. Окей. Но саму операцию-то кто выполняет при этом, которая завёрнута в конечный автомат? Background поток или китайцы педали крутят? Почему-то ни слова об этом не услышал, равно как про ConfigureAwait. Всё самое интересное так и осталось за кадром
Доброго дня. Как вы хотите за 20 мин многопоточность и асинхронность рассказать. Для типовых решений вполне достаточно. Книги почитайте или консультации.
@@alekseev74 да вообще не камень в Ваш огород, спасибо за видео, просто не услышал того, что хотел для себя услышать) По многопоточности видео должно быть вообще на несколько часов, понятное дело)
@@MrAquirier Все ок) Смысл видео в том, что в asp.net чаще всего (не всегда) пиши async/await, ну и как это в entity framework реализовано. Кстати с момента записи видео .net core и ef core уже хорошо развились, работать одно удовольствие.
Операционная система выполняет операцию, ей доступно очень много потоков процессора, она там стоит в очереди на обработку, по-моему так, когда получает результат, то планировщик задач оповещает главный поток, который запустил наш асинхронный метод, вернутся и продолжить код в том методе
Семен, ваша серия роликов по созданию MVC приложения всё еще актуальна? В целом. Просто даже мало иностранных контент-мейкеров делают такие обучающие видео. Разве что tutorialsEU.
В целом да, только конфиг немного изменился. Сейчас актуальна .net 6, уже 7ая на подходе. Пока нет времени перезаписать видео.
Спасибо
Спасибо
Спасибо
Спасибо.