Reputation: 3854
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:
The target in question is an embedded linux system with a 2.18 kernel, therefore there are limitations on memory and compiler features.
Upvotes: 0
Views: 1083
Reputation: 13521
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.
Upvotes: 2
Reputation: 84189
There's Boost.Interprocess library, though I can't comment on its suitability for embedded systems.
Upvotes: 1