Effeciency of IPC, suggestions please!


Scenario: Several different processes written in either C or Perl, all needing to communicate with each other (on the same machine).

I need a central data store, which all processes can read/write to, which I was going to implement as a server/client system, using Unix Domain sockets. But one process will need to be reading/writing to this store up to 20,000+ times a second. Is this wise?

What on earth is the best way to go about doing this? Can I use shmem between both Perl and C (I have _no_ experience of shmem, I only have a vague idea what it does)?

Any suggestions or thoughts on effeciency, suitability, and thoughts on whether this project is doable or not are warmly appreciated.

Many thanks in advance.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

There are several methods I have used for IPC:  shared memory, pipes, sockets, shared files, shared RDBMS...  Each one has it's pros and cons and which one you should use depends completely on the nature of the problem to be solved.

You mention one requirement: r/w 20K+ times/sec.  There is clearly a need for speed.  One thing you fail to mention is if your processes reside all in the same host.  I will assume so.  Another assumption I will make, which is not completely clear from your statement is the architecture.  I will assume this is a server r/w to a data store and many clients talking to the server via IPC.

If you create a server with one channel to read/write to/from clients you get into a contention problem.  You will need to use semaphores or some other mechanism to control who's turn it is to write to the server.  This will bog your service down.  A better approach is to create a multithreaded server, and dedicate one thread to each client so that communications run smoothly.  The contention problem is now shifted to the server kernel, which has to service requests from each thread.  However, since all these threads are in the same process you don't need an expensive semaphore to do this.  You can solve it with a simple token in regular memory indicating which thread has control of the kernel at the time.

If you follow that scheme, your IPC problem is much simpler.  It is just about the communication between your clients and the threads of the server.  Sared memory may prove to be a problem since your OS kernel has room for only so may shmem segments.  Sockets may be a better solution in this case since the OS will determine the best way to route data between the two processes.

A word or caution:  I would build a few small prototypes and put them through the grinder and determine which one provides the best performance and which ones will present stumbling blocks along the way.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Duh!  I failed to read the first statement!  "all needing to communicate with each other (on the same machine)".  Still the principles I outlined earlier apply.

If you use shared memory you will have the contention problem, for which you will need to use something like a semaphore.  This is going to kill your performance.

A better approach might be to create a conversation server which would work as outlined before.
adrianwardAuthor Commented:
Wow, your answer is very complete. Thank you for your effort.

I'm not sure I'm up to implementing all the ideas you have suggested, but your thoughts about multithreaded server was one that I'd previously considered.

However, initially I have rethought the problem through and have tried using shared files - I managed to rejig it so that one process only needs to -receive- data from other processes (this wasn't clear before). So now I have this one process monitoring some files and then whenever another process updates one of these files, the first notices this change (by monitoring the modification date) and re-reads the file.

I know this isn't efficient (at all, infact - it hogs the CPU) but I have found it suitable for my problem, and I'm sure I can improve it's performance a bit more.

Thanks for your effort, though. It's always nice to know what better ways I could achieve things.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux OS Dev

From novice to tech pro — start learning today.