.net - 在Microsoft的CLR中，用于异步方法调用的ref值类型参数存储在哪里？

Question

我了解这是一个实现细节。我实际上很好奇微软的CLR中的实现细节。

现在，请忍受，因为我没有在大学学习CS，所以我可能错过了一些基本原则。

但是，我认为对CLR当今实现的“堆栈”和“堆”的理解是扎实的。例如，我不会做出一些不准确的保护性声明，例如“值类型存储在堆栈中”。但是，在最常见的情况下-值类型的普通 Vanilla 局部变量，可以作为参数传递或在方法内声明，而不包含在闭包内-值类型变量存储在堆栈中(同样，在Microsoft的CLR中)。

我猜我不确定是ref值类型参数从何而来。

最初我在想的是，如果调用堆栈如下所示(左=底部):

A() -> B() -> C()

...然后在 A 范围内声明并作为 ref参数传递给 B 的局部变量仍可以存储在堆栈中，不是吗？ B 只需要在 A 的框架内存储该局部变量的内存位置(如果这不是正确的术语，请原谅；无论如何，我认为我的意思很清楚)。

当我想到可以做到这一点时，我意识到这可能并非完全正确:

delegate void RefAction<T>(ref T arg);

void A()
{
    int x = 100;

    RefAction<int> b = B;

    // This is a non-blocking call; A will return immediately
    // after this.
    b.BeginInvoke(ref x, C, null);
}

void B(ref int arg)
{
    // Putting a sleep here to ensure that A has exited by the time
    // the next line gets executed.
    Thread.Sleep(1000);

    // Where is arg stored right now? The "x" variable
    // from the "A" method should be out of scope... but its value
    // must somehow be known here for this code to make any sense.
    arg += 1;
}

void C(IAsyncResult result)
{
    var asyncResult = (AsyncResult)result;
    var action = (RefAction<int>)asyncResult.AsyncDelegate;

    int output = 0;

    // This variable originally came from A... but then
    // A returned, it got updated by B, and now it's still here.
    action.EndInvoke(ref output, result);

    // ...and this prints "101" as expected (?).
    Console.WriteLine(output);
}

因此，在上面的示例中， x(在 的范围内)存储在哪里？以及这是如何工作的？是盒装的吗？如果不是，尽管是值类型，现在是否仍要进行垃圾回收？还是可以立即回收内存？

对于这个冗长的问题，我深表歉意。但是，即使答案很简单，也可能对将来发现自己在想同样事情的其他人有所帮助。

Answer 1

我不相信当您将BeginInvoke()和EndInvoke()与ref或out参数一起使用时，您实际上是通过ref传递变量的。 我们还必须使用EndInvoke()参数调用ref的事实也应以此为线索。

让我们更改您的示例以演示我描述的行为:

void A()
{
    int x = 100;
    int z = 400;

    RefAction<int> b = B;

    //b.BeginInvoke(ref x, C, null);
    var ar = b.BeginInvoke(ref x, null, null);
    b.EndInvoke(ref z, ar);

    Console.WriteLine(x);  // outputs '100'
    Console.WriteLine(z);  // outputs '101'
}

如果现在检查输出，您将看到x的值实际上是不变的。但是z现在确实包含更新值。

我怀疑当您使用异步Begin/EndInvoke方法时，编译器会通过 ref更改传递变量的语义。

在查看了此代码产生的IL之后，看来 ref的 BeginInvoke()参数仍然传递了 by ref。尽管Reflector没有显示此方法的IL，但我怀疑它根本没有将参数作为 ref参数传递，而是在后台创建了一个单独的变量传递给 B()。然后，当您调用 EndInvoke()时，必须再次提供 ref参数以从异步状态中检索值。此类参数实际上可能存储为 IAsyncResult对象的一部分(或与之一起存储)，该对象是最终检索其值所必需的。

让我们考虑一下为什么这种行为可能会以这种方式起作用。 在对方法进行异步调用时，您是在单独的线程上进行的。该线程具有自己的堆栈，因此不能使用别名 ref/out变量的典型机制。但是，为了从异步方法获取任何返回的值，您最终需要调用 EndInvoke()来完成操作并检索这些值。但是，与原始调用 EndInvoke()或方法的实际主体完全不同，对 BeginInvoke()的调用可能很容易在完全不同的线程上发生。显然，调用堆栈不是存储此类数据的好地方-特别是因为异步操作完成后，用于异步调用的线程可以重新用于其他方法。结果，除了栈外，还需要某种机制来将返回值和out/ref参数“编码(marshal)”到被调用的方法中，并最终返回使用它们的位置。

我相信这种机制(在Microsoft .NET实现中)是 IAsyncResult对象。实际上，如果在调试器中检查 IAsyncResult对象，则会注意到在非公共(public)成员中存在 _replyMsg，其中包含 Properties集合。该集合包含 __OutArgs和 __Return之类的元素，其数据似乎反射(reflect)了自己的名字。

编辑: 这是关于异步委托(delegate)设计的一种理论，对我来说是这样。 似乎 BeginInvoke()和 EndInvoke()的签名被选择为彼此尽可能相似，以避免混淆并提高清晰度。 BeginInvoke()方法实际上不需要接受 ref/out参数-因为它只需要它们的值，而不需要它们的标识(因为它永远不会给它分配任何东西)。但是，例如，有一个接受 BeginInvoke()的 int调用和一个接受 EndInvoke()的 ref int调用真的很奇怪。现在，可能由于技术原因，开始/结束调用应该具有相同的签名-但我认为清晰和对称的好处足以验证这种设计。

当然，所有这些都是CLR和C#编译器的实现细节，并且将来可能会更改。但是，有趣的是，可能会有混淆的可能-如果您希望传递给 BeginInvoke()的原始变量实际上会被修改。它还强调了调用 EndInvoke()完成异步操作的重要性。

也许来自C#团队的人(如果他们看到了这个问题)可以提供对该功能背后的细节和设计选择的更多见解。