Видео

Потому что асинхронное выполнение этих методов не дает никакого приимущества, кроме дополнительного оверхеда. Parallel будет все выпольнять во вторичных потока и как правило "захватит" все доступные ядра,а Task.Run просто захватит еще один поток из пула, и тут же его "заморозит". Единственное когда, вам оборачивание Parrallel в задачу может помочь, это если вам нельзя блокировать вызывающий поток.

@@olegjordan7527 потому что тогда консюмеры не смогу точно быть уверены что все данные были прочитаны.

Ну конечно очень большой проект я не смогу целиком отрецензировать, но выделить какие-нибудь важные или интересные детали вполне смогу. Так что присылайте, посмотрю :)

@@olegjordan7527 в одном из последующих уроков я рассказываю как работает под капотом ConcurrentDictionary

@@lambda4591 да, в течении месяца выйдет первый урок.

Да, метод MoveNext() вызывается неявно при каждом "шаге" автомата.

Да там косяк на виде. Не та база была открыта :)

Да именно так. Если мы сразу поставим Wait() то вызываюший поток будет заблокирован и от await не будет смысла. А в случае с продолжением мы высвобождаем вызывающий поток. А когда вызывается Wait ничего блокироваться не будет, т.к. в этом момент задача будет гарантированно завершена, и обязанность Wait просто бросить исключения если они возникли.

Спасибо! Примерно до 7 блока должны где-то быть, по крайней мере я отдавал их куратору, последних нет, т.к. я сейчас работаю в другом месте.

Ну так получилось. Вообще изначально не планировалось это где-то публиковать, запись велась исключительн "для отчета", а сами уроки поводилсь без подробного сценария, т.к. это были "черновые" прогоны. Чуть позже уже будут нормальные ролики.

Про async await будет чуть позже. И async await это не всегда про многопоточность. А ConfigureAwait это вообще из другой оперы, он связан с контекстом синхронизации, применять его надо далеко не всегда. Обо всем этом я рассказываю в последующих блоках.

Обязательно. :) В ближайшее дни выйдет новый ролик.

Да, верно.

Имеется ввиду, что при большом количестве одновременно работающих потоков время на приключение контекста может "уничтожить" весь профит параллельности. Если же мы с помощью пула ограничим количество одновременно работающих потоков, то тем самым можем увеличить суммарную производительность. Простой пример если у вас будете 10 рабочих и им надо будет выкопать 100 ям, то они это сделают быстрее если каждый работник будет только 1 яму а как выкопает перейдет к другой, чем начать копать сразу 100 и перебегать от одной ямы к другой каждые 10 минут.

Если вы не укажите флаг FileOption.Asynchronous, то ReadAsync будет работать как обычная CPU-задача нагружая процессор, т.е. использования именно задач ввода-вывода не будет.

@@RadmirT Получается лучше всегда ходить при чтение/запись на диск асинхронно, кажется такое поведение наоборот должно быть по умолчанию. А для специфических кейсов уже ставить опцию синхронно. Думаю большенство разработчиков не знают этой фишки)

@@RadmirT или тут есть какие-то подводные камни?

Да, в 99.99% случаев если вы хотите читать файл асинхронно, надо ставить эту опцию. Тут проблема в том, что при создании FileStream никто кроме программиста не знает, как будут читаться данные, синхронно или асинхронно. А читать в синхронном режиме с этим флагом не самая лучшая идея.

Да, во всех ОС общего пользования (Windows, Linux, MacOS). Возможно только какие-нибудь специализированные ОС могу работать по другому.

@@RadmirT спасибо

Стоит различать понятие аутентификации и авторизации. Аутентификация это процесс подтверждения личности пользователя, авторизация это предоставление прав доступа пользователя к защищенному ресурсу. Identity занимается только аутентификацией, те он проверяет что пользователь ввел верные учетные данные, и если они введены верно, то он выдает токен в котором содержатся утверждения (claims) А уже решать предоставлять ли доступ к защищённому ресурсу или нет пользователю с таким набором утверждений должен конкретный сервис, это вы делаете с помощью политик. Конкретному сервису не надо "ходить" в БД Identity всю необходимую информацию о пользователе он должен получать из токена.

@@RadmirT Спасибо!

Джун+, Мидл

Razor и MVC практически одно и тоже. Точнее Razor это один из способов реализации MVC. Единственное отличие от подхода на основе контроллеров это разграничения ответственности. RazorPage может обработать запрос только к одной странице а один контроллер может обслуживать сразу несколько страниц. Но зато у Razor более удобное на мой взгляд взаимодействие между отображением и code behind. Что использование контроллеров что Razor это все страницы генерируемые на сервере, поэтому обе технологии не очень хорошо работают ни AJAX ни с WebAPI. Для этого на много лучше подходят Angular, vue, React и наконец Blazor.

@@RadmirT понял, спасибо

github.com/RadmirT/ASP.NET-Core-cource