views:

170

answers:

2

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.

+1  A: 

There's Boost.Interprocess library, though I can't comment on its suitability for embedded systems.

Nikolai N Fetissov
+2  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.

Todd Gardner
Sure, I absolutely agree with this point of view. I have the opinion that making the proxy class would be a good first step in this direction. Once the access is hidden to the clients it seems it would be much easier to move to another sharing mechanism.
mikelong