C＃app将C ++ dll通过回调返回到C＃app

Question

我正在编写一个调用C ++ DLL的C＃应用​​程序。这个dll是成像系统的设备驱动程序;当获取图像时，可以逐行地从库中获得图像的预览。 C ++ dll采用回调来填充预览，该回调基本上由最终图像的大小，当前扫描的行和数据本身组成。

问题是，从扫描停止和C＃回调停止获取信息的时间起，存在相当严重的延迟。该计划的流程如下：

1. 从C＃
中分配回调C ++ dll
2. 用户开始获取数据
3. 设备启动
4. dll在几秒钟后开始调用回调（正常）
5. 设备完成图像形成
6. dll仍在调用回调图像形成时间的两倍。

这个dll与C ++应用程序一起工作就好了;似乎没有最后一步延迟。但是，在C＃中，如果我立即返回回调，则延迟仍然存在;不管我在回调中做了什么，它就在那里。

这种延迟是否是从非托管代码调用托管代码的固有限制，或者是否有任何一方可以做到这一点以使其更快？我正在与C ++库编写器联系，因此可以从C ++端实现修复。

编辑：可以做一些像命名管道一样简单的工作吗？应用程序可以从自己的管道中读取吗？

Answer 1

检查垃圾收集目标的本机回调的托管调试助手可能是罪魁祸首（它是否在调试器下的调试模式下？）

请参阅Mike Stall撰写的PSA: Pinvokes may be 100x slower under the debugger博客文章。

Answer 2

您是否正在跨互操作层进行任何时髦的数据编组？如果是这样，那么你可能会有很大的延迟，而它基本上是通过转换来编组所有图像数据。你可以很容易地测试这个图像数据越大，它需要的时间越长

想到的一些可能的替代方案是 1.使用内存映射文件，虽然你需要实现一个简单的信号量或信号系统来说'我有数据就绪'和'我已经消耗了数据
2.以混合模式编译C ++ dll（可以使用/ clr标志将任何C ++代码编译为.NET）然后使用C＃/ CLI
3.使用远程处理和IPC频道 - 可能有点过分但值得一看

希望有所帮助

Answer 3

原因是C ++方面的延迟是由开发人员发出的，而不是发誓。