Асинхронизация при продолжении в другом потоке - PullRequest
Новая
       27

Асинхронизация при продолжении в другом потоке

0 голосов
/ 29 июня 2018

Я знаю, что Задача может продолжить выполнение в другом потоке, что подтверждается этим кодом. 

    public async Task Test()
    {
        var id1 = System.Environment.CurrentManagedThreadId;
        await Task.Delay(1000);
        var id2 = System.Environment.CurrentManagedThreadId;
        Console.Write($"First {id1} then {id2}");
    }

Я ожидаю, что фреймворк будет обрабатывать ограничения памяти, так что id1 будет виден при доступе в последнем операторе.

Но что, если вы используете какой-то фреймворк, например NHibernate, где ISession не является потокобезопасным. Фреймворки могут даже проверить, что идентификатор потока все тот же. Как это смешивать?

При создании веб-сайта я буду использовать контейнер IOC с вложенным контейнером для каждого запроса, но когда поток может измениться в рамках одного запроса, не приведет ли это ко всем видам проблем? ThreadStatic не будет работать должным образом

1 Ответ

0 голосов
/ 30 июня 2018

Не будучи поточно-ориентированным, обычно означает, что не используйте его из нескольких потоков одновременно , а не используйте его из одного потока, а затем из другого потока позже.

Я не знаю конкретно о NHibernate, но если это проблема, подумайте об использовании EF Core.

Как правило, в асинхронном режиме не используйте переменные, привязанные к конкретным потокам, например, локальный поток или статический поток.

Однако локальные переменные, члены класса, контексты логического вызова, HttpContext, если вы находитесь на asp.net и т. Д., Продолжают работать. Если у вас есть что-то, что будет потеряно после await, вы можете сначала просто сохранить его в локальной переменной.

Значение по умолчанию ConfigureAwait(true) также восстанавливает некоторый контекст в продолжении, но может быть трудно понять, что восстанавливается, а что нет. Более поздние версии .net справляются с этой задачей лучше, например, восстанавливая культуру, чтобы ресурсы продолжали работать после await.

Здесь есть хорошая статья Стивена Туба: https://blogs.msdn.microsoft.com/pfxteam/2012/06/15/executioncontext-vs-synchronizationcontext/

...