DLL共享数据的推荐方法是什么？

Question

Flow

我有一个用C++编写的读者DLL。 我也有用某种语言编写的编写器DLL（不是在C++中）。 DLL同步在同一进程中运行。

1. Reader DLL调用writer的DLL API，GetData
2. Writer DLL通过下载，提取数据等来准备数据。
3. Reader DLL读取并使用数据

---

Question

DLL共享数据的推荐方法是什么？

---

Approach 1

Reader DLL将文件路径参数传递给Writer DLL并从文件中读取数据。

Cons

我想避免将数据写入磁盘。即使它是最强大的解决方案，我也想探索不同的选项，因为当你不需要在磁盘上将数据写入磁盘时，我似乎并不优雅。

---

Approach 2

Writer DLL将在堆上分配缓冲区并将地址和大小返回给读取器DLL。

Cons

Reader DLL必须释放内存。这可行吗？按地址和大小删除内存？

此外，它可能是跨模块/语言的一个很大的NO-NO分配和释放缓冲区

---

Approach 3

将GetData（）分为两个调用。

1. Reader DLL调用GetDataSize（）
2. Reader DLL分配缓冲区并将地址传递给Writer DLL
3. Writer DLL填充缓冲区
4. Reader DLL使用缓冲区
5. Reader DLL释放缓冲区

这是可接受的WINAPI方法。

Cons

我假设Writer DLL能够在写入之前知道数据的大小，但情况并非总是如此。

---

Approach 4

使用Windows文件映射

Cons

方法2和3的类似缺点。

• 谁将创建文件映射？
• 谁将取消映射？
• 文件映射没有动态大小。您必须在创建时定义大小。

Answer 1

DLL都在相同的进程和地址空间中运行。因此，他们可以直接在内存中共享任何数据。挑战只是如何提供对数据的访问，特别是如果您使用不同的语言。

• 选项1很简单，因为您只需将公共文件名传递给阅读器即可。但为什么这个开销？有一个较轻的字符串变体：如果您设法将文件名作为字符串传递，您也可以让编写器将数据序列化为字符串并将其传递给读者
• 选项2更加精细。如果在DLL的同一侧分配/解除分配内存，或者使用Windows API分配缓冲区，则可以。否则它可能会很棘手因为memory allocation passes the DLL barriers with difficulty（不是因为地址空间，而是因为使用不同堆和不同分配/释放例程的风险）。此外，您无法确定调用程序是否正确管理C ++对象生命周期（如果您在C ++端使用某些RAII设计）。因此，只有在读者管理缓冲区生命周期时，这才是一个选项： 调用者要求读者分配，然后调用者为编写器提供缓冲区的地址，然后调用者再次调用reader来处理数据并释放缓冲区。 固定大小的缓冲区是可接受的，即daa的大小是已知的。
• 选项3是选项2做得很好
• 如果你使用mapped file I/O，选项4仍然有磁盘开销，还有一个问题：你可以在同一个进程中映射两次相同的文件吗？如果您受到此选项的诱惑，请再看一下我为上面的选项1提出的基于字符串的变体：共享字符串扮演内存映射的角色而没有文件的不便。

对于使用复杂数据结构跳过语言障碍，字符串变体似乎是一个简单的选择。几乎每种语言都有字符串。生产者可以在不必事先知道数据大小的情况下构建其字符串。最后，即使字符串在语言中的管理方式不同，也总是有一个way to access them in read-only。

但我的首选变体是组织整个事情，编写器（或作为中介的主程序）根据需要调用读取器的处理函数（当部分数据可用时），提供数据作为参数定义良好的函数调用类型。

Answer 2

注意：由于我们正在讨论在两种不同语言之间传递数据，我将假设我们正在讨论“原始”数据（原始类型，POD和co。），它们不需要对销毁进行任何特殊处理;如果不是这样，请在评论中告诉我。

1. 显然是可行的，但除非绝望，否则我不会考虑它。这两个dll位于相同的虚拟地址空间中，因此它们可以直接在内存中共享数据，而无需通过磁盘。
2. 可行且常规完成;你通常必须解决的问题是，给定模块的“默认”堆通常是private1所以从一个分配并从另一个中释放是一个很大的禁忌。有两种典型的实现方法： 通过两个模块肯定可用的堆;在Win32中，您经常会找到用于此的LocalAlloc / LocalFree（或其他Win32 API提供的堆原语），因为它们在逻辑上“低于”所有用户模式代码，并提供可用于所有模块的共享堆。当前进程;所以，一方知道它必须使用LocalAlloc进行分配，另一方知道必须使用LocalFree解除分配这些数据;一切正常; 分配模块还为其分配的内存提供解除分配功能;客户端代码知道模块A分配的任何内容都必须使用A_free()函数释放。这反过来可能只包装您的语言释放函数，以用作您在“业务逻辑”导出函数中执行的分配的对应部分。顺便说一句，有一个A_malloc()也可能有用来标记预期由A_free()释放的分配 - 即使它们今天可能是普通的malloc / free，你可能有兴趣稍后更改它。
3. 常规也做了;通常在Win32 API中有一些特殊的调用形式，允许检索所需的大小来分配;使用或实现可能很麻烦，如果这样的大小不能轻易计算而不实际尝试做任何函数必须做的事情，或者如果这样的大小波动（想要检索进程数据的Win32 API，你可能需要循环保持如果要检索的数据实际上在一个呼叫和另一个呼叫之间增加，则增加分配。
4. 可以做到，虽然我从来没有看到它为进程内数据做过;分配的开销将大于任何“常规”堆函数，但没有像写入文件那样;一般来说，它比LocalAlloc / LocalFree解决方案更加繁琐，没有特别的收益，所以我不会打扰。

就个人而言，我选择了2 - 它实现起来很简单，并且不需要对你在C中编写这些东西的方式进行大的改动 - 唯一的区别是你必须使用一对特定的分配/释放函数。使用这些数据。

想到一个额外的可能性是让你的函数将分配函数作为回调参数（并且可能还有dellocation函数参数，如果你的算法需要它 - 动态增长的数组会浮现在脑海中）;它将是调用者提供它，因此被调用的DLL将分配调用者最喜欢的任何堆。

---

Notes

1. 虽然它可以共享，例如如果两个模块动态地链接到相同的C运行时，它可能是; OTOH，如果这两个模块用不同的语言编写，这是不太可能的。