C++ 中具有共享内存的远程代理
假设我有一个守护进程，它通过共享内存向各种应用程序共享其内部状态。 进程可以通过命名管道向守护进程发送 IPC 消息以执行各种操作。 在这种情况下，我想为客户端创建一个 C++ 包装类，充当一种“远程代理”，以向客户端隐藏一些血淋淋的细节（同步、消息传递等），并使其更容易隔离代码单元测试。
我有三个问题：
- 一般来说，这是一个好主意/方法吗？
- 您对此设置中的同步有任何提示或陷阱吗？或者使用标准的读写器互斥设置就足够了吗？
- 有什么我应该考虑的框架吗？
所讨论的目标是具有 2.18 内核的嵌入式 Linux 系统，因此内存和编译器功能存在限制。
Suppose I have a daemon that is sharing it's internal state to various applications via shared memory. Processes can send IPC messages to the daemon on a named pipe to perform various operations. In this scenario, I would like to create a C++ wrapper class for clients that acts as a kind of "Remote Proxy" to hide some of the gory details (synchronization, message passing, etc) from clients and make it easier to isolate code for unit tests.
I have three questions:
- Generally, is this a good idea/approach?
- Do you have any tips or gotchas for synchronization in this setup, or is it enough to use a standard reader-writer mutex setup?
- Are there any frameworks that I should consider?
The target in question is an embedded linux system with a 2.18 kernel, therefore there are limitations on memory and compiler features.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Herb Sutter 有一篇文章共享是所有争用的根源< /a> 我基本同意； 如果您使用共享内存架构，您就会面临很多潜在的线程问题。
客户端/服务器模型可以使事情变得非常简单，其中客户端写入命名服务器管道，服务器在唯一的客户端管道上写回（或使用套接字）。 它还将使单元测试更简单（因为您不必担心测试共享内存），可以避免互斥等。
Herb Sutter had an article Sharing Is the Root of All Contention that I broadly agree with; if you are using a shared memory architecture, you are exposing yourself to quite a bit of potential threading problems.
A client/server model can make things drastically simpler, where clients write to the named server pipe, and the server writes back on a unique client pipe (or use sockets). It would also make unit testing simpler (since you don't have to worry about testing shared memory), could avoid mutexing, etc.
有 Boost.Interprocess 库，但我可以'不评论其对嵌入式系统的适用性。
There's Boost.Interprocess library, though I can't comment on its suitability for embedded systems.