Блог

Я импортировал Microsoft.VisualStudio.Поток в .Веб-приложение Net Core. Я сделал это специально для использования AsyncLazy<T> .

Я хотел убедиться, что я сделал это правильно, поэтому я импортировал соответствующие анализаторы.

В предупреждениях и документации четко указано, что JoinableTaskFactory следует внедрить в мою реализацию.

Мой вопрос в том, как я должен создать его JoinableTaskFactory в конфигурации моего веб-приложения .Net Core?

Это так просто, как

 public void ConfigureServices(IServiceCollection services)
{
    // ...
        services.AddSingleton(new JoinableTaskFactory());
    // ...
}
  

или это все неправильно?

Да, вы можете использовать Microsoft.VisualStudio.Threading библиотеку в ASP.NET Основные приложения. Но хотя JoinableTaskFactory в таком приложении «работает», это довольно хороший признак того, что вы делаете что-то не так.

Анализаторы, конечно, всегда уместны, и предупреждения, которые вы видели, возможно, указывали на то, что вам не следует вызывать Task.Result , Task.Wait() и т.д. Они синхронно блокируют потоки и могут серьезно снизить масштабируемость вашего веб-приложения (или любого приложения, если на то пошло). Вы должны использовать await вместо этого везде, где это возможно.

JoinableTaskFactory можно ли вмешаться, когда вы не можете использовать await, но вам все равно нужно вызвать асинхронный код. Использование JTF.Run по-прежнему будет блокировать вызывающий поток, но это будет сделано таким образом, чтобы избежать взаимоблокировок, когда у вас есть однопоточный SynchronizationContext в приложении. Я не думаю, что в ASP.NET Core есть такая вещь, так что это не проблема. JTF.Run все еще более эффективен, чем Task.Wait , поскольку он может повторно использовать исходный поток для продолжения вместо второго потока.

Если вы решите использовать JTF в своем веб-приложении, если ASP.NET Ядро не использует однопоточный SynchronizationContext тогда вы можете создать один экземпляр JTF и предоставить общий доступ ко всему приложению. Но если у него есть однопоточный SynchronizationContext , он будет по одному на веб-запрос, что означает, что вам нужно создать новый JoinableTaskContext для каждого запроса, поскольку они привязаны к одному SynchronizationContext . Вы всегда получаете свой экземпляр JTF из JoinableTaskContext экземпляра.

На этой странице документов vs-threading говорится

ThreadHelper.Свойство JoinableTaskFactory работает только для кода, выполняемого в процессе VS. Если в вашем коде заканчивается процедура (в vstest.executionengine.exe например, runner) это не сработает.

Итак, как следует из названия пакета, Microsoft.VisualStudio.Threading , он предназначен для использования с расширениями Visual Studio. Код, который вы связали для его реализации AsyncLazy, использует JoinableTaskFactory, поэтому он, вероятно, не подходит за пределами Visual Studio. Я, конечно, никогда бы не использовал его вне расширения VS, которому необходимо переключиться на поток пользовательского интерфейса.

У библиотеки AsyncExСтивена Клири есть AsyncLazy, а страница wiki ссылается на это сообщение в блоге Стивена Тоуба под названием AsyncLazy. В сообщении в блоге указывается, что отложенная семантика на самом деле мало что добавляет по сравнению с тем, что Task<T> предоставляет, хотя, поскольку фабрика значений может проделать большую работу до достижения ожидания, его образец запускает его в пуле потоков и разворачивает Task<Task<T>> .

редактировать: Как указано в комментариях, моя цитата из документов несколько вырвана из контекста. Однако библиотека vs-threading предназначена для предотвращения взаимоблокировок при использовании асинхронности с контекстом синхронизации (в первую очередь с графическим интерфейсом). ASP.NET Ядро, которое использует автор вопроса, не имеет контекста синхронизации, следовательно, ему не нужно беспокоиться о блокировке основного потока конкретно. Хотя использование библиотеки vs-threading, вероятно, не вызовет проблем, как утверждалось в моей цитате, я все же не думаю, что она подходит для чего-либо без контекста синхронизации, и есть гораздо лучшие альтернативы, такие как использование Task<T> напрямую и не требующие какой-либо реализации AsyncLazy.