C++ 进程间通信的最佳方式

发布于 2024-07-10 04:58:42 字数 224 浏览 5 评论 0原文

我有两个进程,一个进程将查询另一个进程的数据。在有限的时间内(每秒 10000 个)将会有大量的查询,并且每秒将传输数据(> 100 mb)。数据类型将是整数类型(双精度,整数) 我的问题是通过什么方式连接这个过程?

共享内存,消息队列,lpc(本地过程调用)或其他......

我还想问你建议哪个库? 顺便说一句,请不要建议 MPI。 编辑:在Windows XP 32位下

I have two processes one will query other for data.There will be huge amount of queries in a limited time (10000 per second) and data (>100 mb) will be transferred per second.Type of data will be an integral type(double,int)
My question is in which way to connect this process?

Shared memory , message queue , lpc(Local Procedure call) or others....

And also i want to ask which library you suggest? by the way please do not suggest MPI.
edit : under windows xp 32 bit

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

や三分注定 2024-07-17 04:58:42

一个词:Boost.InterProcess。 如果确实需要快速,那么共享内存是最佳选择。 由于操作系统在虚拟地址和物理地址之间进行通常的映射,并且不需要数据复制,因此开销几乎为零。 您只需要注意并发问题。

对于实际发送诸如“关闭”和“查询”之类的命令,我将使用消息队列。 在我知道 boost 之前,我以前使用本地主机网络编程来做到这一点,并使用手动共享内存分配。 该死的,如果我需要重写应用程序,我会立即选择 boost。 Boost.InterProcess 使这对您来说更容易。 一探究竟。

One Word: Boost.InterProcess. If it really needs to be fast, shared memory is the way to go. You nearly have zero overhead as the operation system does the usual mapping between virtual and physical addresses and no copy is required for the data. You just have to lookout for concurrency issues.

For actually sending commands like shutdown and query, I would use message queues. I previously used localhost network programming to do that, and used manual shared memory allocation, before i knew about boost. Damn if i would need to rewrite the app, I would immediately pick boost. Boost.InterProcess makes this more easy for you. Check it out.

临走之时 2024-07-17 04:58:42

我将使用共享内存来存储数据,并使用消息队列来发送查询。

I would use shared memory to store the data, and message queues to send the queries.

酷炫老祖宗 2024-07-17 04:58:42

我会赞同 Marc 的建议——除非你有可移植性问题或者想要做一些很酷的事情,比如在共享内存上映射标准容器类型(在这种情况下我肯定会使用 boost),否则我不会费心使用 boost。

否则,消息队列和共享内存的处理就非常简单。

I'll second Marc's suggestion -- I'd not bother with boost unless you have a portability concern or want to do cool stuff like map standard container types over shared memory (in which case I'd definitely use boost).

Otherwise, message queues and shared memory are pretty simple to deal with.

糖粟与秋泊 2024-07-17 04:58:42

如果您的数据包含多种类型和/或您需要互斥锁之类的东西,请使用 Boost。
否则,使用 #pragma data_seg 或内存映射文件来使用共享内存部分。

If your data consists of multiple types and/or you need things like mutex, use Boost.
Else use a shared section of memory using #pragma data_seg or a memory mapped file.

笛声青案梦长安 2024-07-17 04:58:42

如果您确实使用共享内存,您将必须决定是否旋转。 我预计,如果您使用信号量进行同步并将数据存储在共享内存中,与使用消息队列相比,您不会获得太多性能优势(清晰度显着下降),但如果您旋转原子变量进行同步,那么您必须承受由此带来的后果。

If you do use shared memory you will have to decide whether or not to spin or not. I'd expect that if you use a semaphore for synchronization and storing data in shared memory you will not get much performance benefit compared to using message queues (at significant clarity degradation), but if you spin on an atomic variable for synchronization, then you have to suffer the consequences of that.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文