.NET 中父子进程之间的 IPC 建议？
我的 .NET 程序需要运行一个大量使用第三方库（32 位）的算法，其中大部分是非托管代码。我想尽可能地驱动 CPU，因此代码并行运行多个线程来划分工作。
我发现同时运行所有这些线程会导致临时内存峰值，导致进程的虚拟内存大小接近 2 GB 限制。此内存会很快释放回来，但有时，如果有足够多的线程同时输入错误的代码部分，则进程会越过“红线”，并且非托管代码或 .NET 代码会遇到内存不足错误。我可以减少线程数量，但 CPU 使用率却没有我想要的那么高。
我正在考虑创建工作进程而不是工作线程来帮助避免内存不足错误，因为这样做会给每个执行线程提供自己的 2 GB 虚拟地址空间（我的机器有大量 RAM）。我想知道 .NET 中进程之间通信输入和输出的最佳/最简单方法是什么？
文件系统是一个显而易见的选择。我从 UNIX 背景就习惯了共享内存、命名管道等。我应该使用 Windows 或 .NET 特定机制吗？
My .NET program needs to run an algorithm that makes heavy use of 3rd party libraries (32-bit), most of which are unmanaged code. I want to drive the CPU as hard as I can, so the code runs several threads in parallel to divide up the work.
I find that running all these threads simultaneously results in temporary memory spikes, causing the process' virtual memory size to approach the 2 GB limit. This memory is released back pretty quickly, but occasionally if enough threads enter the wrong sections of code at once, the process crosses the "red line" and either the unmanaged code or the .NET code encounters an out of memory error. I can throttle back the number of threads but then my CPU usage is not as high as I would like.
I am thinking of creating worker processes rather than worker threads to help avoid the out of memory errors, since doing so would give each thread of execution its own 2 GB of virtual address space (my box has lots of RAM). I am wondering what are the best/easiest methods to communicate the input and output between the processes in .NET?
The file system is an obvious choice. I am used to shared memory, named pipes, and such from my UNIX background. Is there a Windows or .NET specific mechanism I should use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
.NET 3.0+ 中的 IPC 可以通过 WCF 和命名管道绑定来完成。最明显的好处是，您可以通过简单地切换绑定来将繁重的任务分散到不同的机器上。有关此内容的更多信息，请此处。
关于内存占用，您可以尝试将 3rd 方库设置为 64 位，并在 64 位操作系统上运行您的内容，以获得更多可供进程使用的内存。
IPC in .NET 3.0+ can be done with WCF and named pipes binding. The most obvious benefit is that you can split your heavy tasks across machines by simply switching the binding. More on this here.
Regarding memory footprint you may try to get your 3rd party libraries in 64-bit and run your stuff on 64-bit OS to get more memory available to your process.
如果您使用 WPF，则可以使用许多常见形式的 IPC。这可以通过以下方式完成：只需更改配置文件，并为跨机器边界通信留出空间。
If you use WPF, many common forms of IPC are available. This can be done in such a way that config file changes are all that is required, and leaves room for communicating across machine boundaries as well.
是的你是对的。与线程相反，分成多个进程会有所帮助，因为每个进程都有自己的 2GB 虚拟空间（在 32 位系统上）。
由于您有大量 RAM，您可以做的另一件事（无需多个进程）是使用 PAE（物理地址扩展），然后您的进程可以寻址到 8 GB 以上。请参阅此处
正如其他人建议的那样，您可以使用 .NET 远程处理（如果客户端和服务器都是.NET，则可以在同一台计算机上本地或远程）。
PS：这个答案已经晚了，可能是您的要求已经完成，但我将其发布在这里以供其他人稍后使用该线程。
Yes you are right. Breaking into several processes as opposed to threads will help, since every process will have its own 2GB virtual space (on 32-bit system).
Since you have lots of RAM, One other thing you can do (without need to have multiple processes) is use PAE (physical address extension) and then your process can address upwards of 8 GB . See here
As others have suggested you can use .NET remoting (if both client and server are .NET, can be local in same machine or remote).
PS: this answer is late, may be your requirement is done with, but i post it here for later use of this thread by other people.