Что мне делать с асинхронными задачами, которых я не хочу ждать?

Насколько я понимаю, суть в том, что вы хотите:

while (!shutdown)
{
    //This should happen immediately and completions occur on the main thread.
    foreach (var actor in actors)
        actor.Update(); //includes i/o bound database operations

    // The subsequent code should not be delayed
   ...
}

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

await async - не лучший вариант в этом цикле, вам нужно запускать эти задачи ввода-вывода базы данных в пуле потоков. В пуле потоков async await может быть полезен для освобождения потоков пула.

Итак, следующий вопрос - как вернуть эти доработки в ваш основной поток. Что ж, похоже, вам нужно что-то эквивалентное перекачке сообщений в вашем основном потоке. См. этот пост, чтобы узнать, как это сделать, хотя это может быть немного тяжеловесно. У вас может быть просто своего рода очередь завершения, которую вы проверяете в основном потоке при каждом проходе через цикл while. Для сделайте это так, чтобы все было потокобезопасным, затем установите Foo, если это необходимо.

Кажется, что есть место для рационализации этого опроса участников и потоковой передачи, но, не зная подробностей приложения, трудно сказать.

Пара моментов: -

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

• Как вы отметили, await async не блокирует текущий поток, но это означает, что код, следующий за await, будет выполняться только после завершения ожидания.

• Завершение может или не может быть завершено в вызывающем потоке. Вы уже упомянули контекст синхронизации, поэтому я не буду вдаваться в подробности.

• Контекст синхронизации в консольном приложении равен нулю. Дополнительную информацию см. здесь.

• Async на самом деле не для операций типа «запустил и забыл».

Чтобы выстрелить и забыть, вы можете использовать один из следующих вариантов в зависимости от вашего сценария:

• Используйте Task.Run или Task.StartNew. См. здесь, чтобы узнать о различиях.
• Используйте шаблон типа производитель / потребитель для длительных сценариев, работающих под вашим собственным пулом потоков.

Имейте в виду следующее:

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

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

Во-первых, я рекомендую вам не использовать свои собственные SynchronizationContext; У меня есть один доступный как часть моей библиотеки AsyncEx, которую я обычно использую для консольных приложений.

Что касается ваших методов обновления, они должны возвращать Task. Моя библиотека AsyncEx имеет ряд «констант задач», которые полезны, когда у вас есть метод, который может быть асинхронным:

public override Task Update() // Note: not "async"
{
  foo.DoThings();

  if (someCondition) {
    return UpdateAsync();
  }
  else {
    return TaskConstants.Completed;
  }
}

async Task UpdateAsync()
{
  // Get data, but let the server continue in the mean time
  var newFoo = await GetFooFromDatabase();

  // Now back on the main thread, update game state
  this.foo = newFoo;
}

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

AsyncContext.Run(async () =>
{
  while (!shutdown)
  {
    foreach (var actor in actors)
      await actor.Update();
    ...
  }
});

В качестве альтернативы, если вы хотите запустить всех актеров одновременно и дождаться их завершения, прежде чем перейти к следующей «галочке», вы можете сделать это:

AsyncContext.Run(async () =>
{
  while (!shutdown)
  {
    await Task.WhenAll(actors.Select(actor => actor.Update()));
    ...
  }
});

Когда я говорю «одновременно» выше, это фактически запускает каждого актора по порядку, и поскольку все они выполняются в основном потоке (включая async продолжения), фактического одновременного поведения нет; каждый «кусок кода» будет выполняться в одном и том же потоке.

Я настоятельно рекомендую посмотреть это видео или просто взглянуть на слайды: Три основных совета по использованию асинхронного режима в Microsoft Visual C # и Visual Basic

Насколько я понимаю, то, что вам, вероятно, следует делать в этом сценарии, возвращает Task<Thing> в UpdateAsync и, возможно, даже Update.

Если вы выполняете некоторые асинхронные операции с «foo» вне основного цикла, что произойдет, когда асинхронная часть завершится во время будущего последовательного обновления? Я считаю, что вы действительно хотите дождаться завершения всех ваших задач по обновлению, а затем поменять свое внутреннее состояние за один раз.

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