Используя переменные ThreadStatic с async/wait

Ответ 1

Вы можете использовать CallContext.LogicalSetData и CallContext.LogicalGetData, но я рекомендую вас не потому, что они не поддерживают какой-либо "клонирование" при использовании простого parallelism (Task.WhenAny/Task.WhenAll).

Я открыл запрос UserVoice для более полного async -совместимого "контекста", более подробно описанного в сообщение форума MSDN. Кажется невозможным построить один самостоятельно. У Jon Skeet есть хорошая запись в блоге по этому вопросу.

Итак, я рекомендую использовать аргумент, лямбда-закрытие или члены локального экземпляра (this), как описано в Marc.

И да, OperationContext.Current не сохраняется на await s.

Обновление:..NET 4.5 поддерживает Logical[Get|Set]Data в async. Подробности в моем блоге.

Ответ 2

В принципе, я хотел бы подчеркнуть: не делайте этого. [ThreadStatic] никогда не будет хорошо играть с кодом, который перескакивает между потоками.

Но вам это не нужно. A Task уже имеет состояние - фактически, он может сделать это двумя разными способами:

• есть явный объект состояния, который может содержать все, что вам нужно
• lambdas/anon-methods могут образовывать замыкания по состоянию

Кроме того, компилятор делает все, что вам нужно здесь:

private static async Task Start()
{
    string secret = "moo moo";
    Console.WriteLine("Started on thread [{0}]",
        Thread.CurrentThread.ManagedThreadId);
    Console.WriteLine("Secret is [{0}]", secret);

    await Sleepy();

    Console.WriteLine("Finished on thread [{0}]",
        Thread.CurrentThread.ManagedThreadId);
    Console.WriteLine("Secret is [{0}]", secret);
}

Нет статического состояния; нет проблем с потоками или несколькими задачами. Это просто работает. Обратите внимание, что secret здесь не просто "локальный"; компилятор работал несколько вуду, как и с итераторными блоками и захваченными переменными. Проверяя отражатель, я получаю:

[CompilerGenerated]
private struct <Start>d__0 : IAsyncStateMachine
{
    // ... lots more here not shown
    public string <secret>5__1;
}

Ответ 3

Для продолжения выполнения задачи в одном потоке требуется поставщик синхронизации. Это дорогое слово, простая диагностика - это посмотреть на значение System.Threading.SynchronizationContext.Current в отладчике.

Это значение будет null в приложении консоли. Существует не провайдер, который может сделать код запуска в определенном потоке в приложении режима консоли. Только приложение Winforms или WPF или приложение ASP.NET будут иметь поставщика. И только по их основной теме.

Основной поток этих приложений делает что-то очень особенное, у них есть диспетчерский цикл (например, цикл сообщений или насос сообщений). Что реализует общее решение проблемы производителя-потребителя. Это тот цикл диспетчера, который позволяет передавать потоку некоторую работу для выполнения. Такая небольшая работа будет продолжением задачи после выражения ожидания. И этот бит будет работать в потоке диспетчера.

WindowsFormsSynchronizationContext является поставщиком синхронизации для приложения Winforms. Он использует Control.Begin/Invoke() для отправки запроса. Для WPF это класс DispatcherSynchronizationContext, он использует Dispatcher.Begin/Invoke() для отправки запроса. Для ASP.NET это класс AspNetSynchronizationContext, он использует невидимую внутреннюю сантехнику. Они создают экземпляр своих соответствующих поставщиков при их инициализации и назначают его SynchronizationContext.Current

Нет такого провайдера для приложения в консольном режиме. Прежде всего потому, что основной поток полностью непригоден, он не использует цикл диспетчера. Вы бы создали свой собственный, а затем создали свой собственный производный класс SynchronizationContext. Трудно сделать, вы не можете сделать вызов, например Console.ReadLine(), поскольку это полностью замораживает основной поток при вызове Windows. Приложение в консольном режиме перестает быть консольным приложением, оно начнет напоминать приложение Winforms.

Обратите внимание, что в этих средах среды выполнения есть поставщики синхронизации по уважительной причине. У них есть, потому что графический интерфейс является принципиально небезопасным. Не проблема с консолью, она является потокобезопасной.

Ответ 4

Посмотрите на эту тему

В полях, помеченных ThreadStaticAttribute, инициализация происходит только один раз в статическом конструкторе. В вашем коде при создании нового потока с идентификатором 11 будет создано новое секретное поле, но оно будет пустым/пустым. При возврате к задаче "Пуск" после вызова await задача завершится в потоке 11 (как показывает ваша распечатка), и поэтому строка пуста.

Вы можете решить свою проблему, сохранив Секрет в локальном поле внутри "Пуск" непосредственно перед вызовом Sleepy, а затем восстановите Секрет из локального поля после возвращения из Sleepy. Вы также можете сделать это в Sleepy непосредственно перед вызовом "await Task.Delay(1000);" это фактически вызывает переключение потока.

Ответ 5

AsyncLocal <T> предоставляет поддержку для поддержки переменных, ограниченных определенным потоком асинхронного кода.

Изменение типа переменной на AsyncLocal, например,

private static AsyncLocal<string> Secret = new AsyncLocal<string>();

дает следующий желаемый результат:

Started on thread [5]
Secret is [moo moo]
Was on thread [5]
Now on thread [6]
Finished on thread [6]
Secret is [moo moo]