Асинхронная рекурсия. Где моя память действительно идет?

Question

Это задается скорее из любопытства, чем с точки зрения реальной проблемы.

Рассмотрим следующий код:

void Main() 
{ 
    FAsync().Wait(); 
} 

async Task FAsync() 
{ 
    await Task.Yield(); 
    await FAsync(); 
} 

В синхронном мире, это в конечном счете приведет к StackOverflow.

В асинхронном мире, это просто потребляет много памяти (который я предполагаю, это связано с чем-то, что я мог бы свободно называть «асинхронный стек»?)

Что именно это эти данные, и как это Ручной?

Answer 1

Хороший вопрос.

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

В асинхронной ситуации вся эта информация хранится в куче. Задача содержит делегат, который вызывается, когда задача завершена. Делегат связан с экземпляром класса «закрытия», который содержит поля для любых локальных переменных или другого состояния. И, конечно же, задачи сами являются объектами кучи.

Вы можете спросить: если это так, что продолжение является делегатом, который вызывается после завершения задачи, как то код, который завершает задачу не в стеке вызовов в точке, где завершенности казнят? Задача может выбрать вызов делегата продолжения на , проводя сообщение Windows, и когда цикл сообщения обрабатывает сообщение, он выполняет вызов. Таким образом, вызов затем находится на «вершине» стека, где обычно сидит контур сообщения. (Точные детали стратегии вызова, используемые для продолжения, зависят от контекста, в котором создается задача, см. Более подробное руководство по параллельной библиотеке задач для деталей.)

Хорошая вступительная статья о том, как это все работы можно найти здесь:

https://msdn.microsoft.com/en-us/magazine/hh456403.aspx

некоторые детали были изменены с момента Мадс писал, что статья, но идеи звук. (Ответ i3arnon иллюстрирует, как это произошло, в статье Mads все идет в кучу, но в некоторых сценариях получается избыточный мусор. Более сложный codegen позволяет нам хранить некоторую информацию в стеке. Понимание этого различия не необходимо, чтобы увидеть, как логически представлены продолжения.)

Это развлекательное и просветительское упражнение, чтобы взять вашу программу и на самом деле вытащить всех созданных делегатов и задач, а также то, что ссылки между ними. Дать ему шанс!

Answer 2

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

Например, этот метод:

public async Task M() 
{ 
} 

включен в это состояние машины:

private struct <M>d__0 : IAsyncStateMachine 
{ 
    public int <>1__state; 
    public AsyncTaskMethodBuilder <>t__builder; 
    void IAsyncStateMachine.MoveNext() 
    { 
     try 
     { 
     } 
     catch (Exception exception) 
     { 
      this.<>1__state = -2; 
      this.<>t__builder.SetException(exception); 
      return; 
     } 
     this.<>1__state = -2; 
     this.<>t__builder.SetResult(); 
    } 
    [DebuggerHidden] 
    void IAsyncStateMachine.SetStateMachine(IAsyncStateMachine stateMachine) 
    { 
     this.<>t__builder.SetStateMachine(stateMachine); 
    } 
} 

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