Неожиданное поведение после возврата из ожидания

В моем блоге есть описание того, как async методы возобновляют работу после await. По сути, await захватывает текущий SynchronizationContext, если это не null, и в этом случае он захватывает текущий TaskScheduler. Затем этот «контекст» используется для планирования оставшейся части метода.

Поскольку вы выполняете консольное приложение, SynchronizationContext нет, а TaskScheduler по умолчанию фиксируется для выполнения оставшейся части метода async. Этот контекст ставит в очередь метод async в пул потоков. Невозможно вернуться к основному потоку консольного приложения, если вы фактически не зададите ему основной цикл с SynchronizationContext (или TaskScheduler), который ставится в очередь к этому основному циклу.

Прочитайте Все о контексте синхронизации, и я уверен, стать менее запутанным. Поведение, которое вы видите, имеет смысл. Task.Delay использует внутренние API Win32 Kernel Timer (а именно, CreateTimerQueueTimer). Обратный вызов таймера вызывается в потоке пула, отличном от вашего потока Main. Вот где остальная часть Poetry после await продолжает выполняться. Так работает планировщик задач по умолчанию при отсутствии контекста синхронизации в исходном потоке, инициировавшем await.

Поскольку вы не выполняете await задачу Poetry() (и вы не можете этого сделать, пока не вернете Task вместо void), его цикл for продолжает выполняться параллельно с циклом while в вашем Main. Почему и, что более важно, как вы ожидаете, что он будет "принудительно" возвращен в поток Main? Для этого должна быть какая-то явная точка синхронизации, поток не может просто прерваться в середине цикла while.

В приложении пользовательского интерфейса основной цикл обработки сообщений может служить точкой синхронизации такого рода. Например. для приложения WinForms WindowsFormsSynchronizationContext сделает это возможным. Если await Task.Delay() вызывается в основном потоке пользовательского интерфейса, код после await будет асинхронно продолжаться в основном потоке пользовательского интерфейса после некоторой будущей итерации цикла сообщений, выполняемого Application.Run.

Таким образом, если бы это был поток пользовательского интерфейса, остальная часть Poetry не выполнялась бы параллельно с циклом while, следующим за вызовом Poetry(). Скорее, он будет выполнен, когда поток управления вернется в цикл обработки сообщений. Или вы можете явно перекачивать сообщения с Application.DoEvents() для продолжения, хотя я бы не рекомендовал этого делать.

Кстати, не используйте async void, а используйте async Task, подробнее< /а>.

void async Main()
{
   await Poetry();
   while (true)
   {
       Console.WriteLine("Outside, within Main.");
      Thread.Sleep(200);
   }
}

async Task Poetry()

class Program
{
    static void Main(string[] args)
    {
        RunMain();

        // pause long enough for all async routines to complete (10 minutes)
        System.Threading.Thread.Sleep(10 * 60 * 1000);
    }

    private static async void RunMain()
    {
        // with await this will pause for poetry
        await Poetry();

        // without await this just runs
        // Poetry();

        for (int main = 0; main < 25; main++)
        {
            System.Threading.Thread.Sleep(10);
            Console.WriteLine("MAIN [" + main + "]");
        }
    }

    private static async Task Poetry()
    {
        await Task.Delay(10);
        for (int i = 0; i < 10; i++)
        {
            Console.WriteLine("IN THE POETRY ROUTINE [" + i + "]");
            System.Threading.Thread.Sleep(10);
        }
    }
}

Удачного тестирования! О, и вы по-прежнему можете прочитать дополнительную информацию здесь.

Я хотел бы ответить на свой вопрос здесь.

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

Итак, Task.Delay использует Timer, который использует операционную систему для запуска события через N миллисекунд. после этого периода создается новый объединенный поток, который практически ничего не делает.

Ключевое слово await означает, что после того, как поток завершится (и он почти ничего не делает), он должен продолжить выполнение всего, что идет после ключевого слова await.

Здесь идет контекст синхронизации, как упоминалось в других ответах.

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

Если есть синхронизирующий контекст, вновь созданный пул-поток будет только подталкивать все, что идет после ожидания, в синхронизирующий контекст.

Ради этого, вот несколько моментов, которые я не понял:

• Async/await не делает ничего, что раньше было невозможно (технически говоря). Просто, может быть, удивительно неуклюжий.
• Это просто поддержка языка для некоторых классов .NET 4.5.
• Это очень похоже на доходность. Он может разбить ваш метод на несколько методов, может даже сгенерировать класс позади него и использовать некоторые методы из BCL, но не более того.

В любом случае, я рекомендую прочитать главу C# 5.0 In A Nutshell "Параллелизм и асинхронность". Это мне очень помогло. Это здорово, и на самом деле объясняет всю историю.