c++ - C#/C++ 异步反向 pinvoke？

Question

我需要从 native C/C++ .dll 调用 C# 代码 异步 .

在搜索如何做时，我发现我可以创建一个 C# 委托(delegate)并从中获取一个函数指针，我将在我的 native 代码中使用它。

问题是我的 native 代码需要运行 异步 ，即在从 native 代码创建的单独线程中，这意味着从 C# 调用的 native 代码将在调用委托(delegate)之前返回到 C#。

我在另一个 SO 问题中读到有人对此有问题，尽管 MSDN 怎么说 ，因为他的委托(delegate)在被调用之前就被垃圾收集了，因为他的任务是异步的。

我的问题是:是否真的可以使用来自在 native 代码中创建的线程中运行的 native 代码的函数指针调用 C# 委托(delegate)？谢谢你。

Answer 1

不，这是一个通用错误，并非特定于异步代码。在您的情况下，字节更有可能发生，因为您从来没有 [DllImport] 背后的机制来让您远离麻烦。我会解释为什么会出错，也许这会有所帮助。

回调方法的委托(delegate)声明总是需要的，这就是 CLR 现在知道调用方法的方式。您经常使用 delegate 关键字显式声明它，如果非托管代码是 32 位并且假定函数是用 C 或 C++ 编写的，则可能需要应用 [UnmanagedFunctionPointer] 属性。声明很重要，这就是 CLR 知道您从 native 代码传递的参数需要如何转换为其托管等效项的方式。如果您的 native 代码将字符串、数组或结构传递给回调，那么这种转换可能会很复杂。

该场景在 CLR 中进行了大量优化，这很重要，因为托管代码不可避免地在非托管操作系统上运行。有很多这样的转换，你看不到它们，因为它们大部分发生在 .NET Framework 代码中。这个优化涉及到 thunk ，一小段自动生成的机器代码，负责调用外部方法或函数。每当您进行使用委托(delegate)的互操作调用时，都会即时创建 Thunk。在 C# 代码将委托(delegate)传递给 C++ 代码的情况下。你的 C++ 代码得到一个指向 thunk 的指针，一个函数指针，你存储它并稍后进行回调。

“你存储它”是问题开始的地方。 CLR 不知道您存储了指向 thunk 的指针，垃圾收集器看不到它。 Thunk 需要内存，通常只有少数几个字节用于机器代码。它们不会永远存在，当不再需要 thunk 时，CLR 会自动释放内存。

“不再需要”是个问题，您的 C++ 代码无法神奇地告诉 CLR 它不再进行回调。所以它使用的简单而明显的规则是当委托(delegate)对象被垃圾收集时，thunk 被销毁。

程序员永远都会遇到这个规则的麻烦。他们没有意识到委托(delegate)对象的生命周期很重要。在 C# 中尤其棘手，它有很多语法糖，可以很容易地创建委托(delegate)对象。您甚至不必使用 new 关键字或命名委托(delegate)类型，只需使用目标方法名称就足够了。这种委托(delegate)对象的生命周期只是 pinvoke 调用。在调用完成并且您的 C++ 代码已存储指针后，委托(delegate)对象不再在任何地方被引用，因此有资格进行垃圾回收。

发生这种情况以及 thunk 被破坏的确切时间是不可预测的。 GC 仅在需要时运行。在您调用电话后可能是一纳秒，当然这不太可能，可能是几秒钟。最棘手的是，永远不可能。发生在不显式调用 GC.Collect() 的典型单元测试中。单元测试很少对 GC 堆施加足够的压力来引发收集。当您从另一个线程进行回调时更有可能，隐含的是其他代码正在其他线程上运行，这使得更可能触发 GC。你会更快地发现问题。尽管如此，thunk 迟早会在真正的程序中被销毁。之后在 C++ 代码中进行回调时 Kaboom。

所以，坚如磐石的规则，你必须存储对委托(delegate)的引用以避免过早收集问题。做起来很简单，只需将它存储在 C# 程序中声明为 static 的变量中。 .通常足够好，当 C# 代码告诉您的 C++ 代码停止进行回调时，您可能希望将其显式设置回 null，在您的情况下不太可能。偶尔，您会想要使用 GCHandle.Alloc()而不是静态变量。