Hi all,

I am working on an embedded Linux project. I have multiple processes running in the user space. Now I need to choose a way for the process to communicate with each other. I read about SOCKET & MESSAGE QUEUE. Could anyone give me an idea which one I should use for embedded Linux system?

Thanks,
Wei Xu

It really depends on what and how fast you need the data passed.

For fastest, use shared memory segments. Neither socket or message queues are all that fast. Sockets are easiest as the kernel does the buffering. I haven't used message queues but I believe they cause some extra synchronization overhead.

The best would be to try all three, then pick the one that works best for your application.

Message queues ... "pipes" ... are probably plenty fast enough.

Linux makes fairly-constant use of pipes. Anytime you use the "|" character when "piping" one command to another in the (bash) shell, you're using pipes. Therefore, the implementation is easy-to-use and fast.

All that having been said . . . When possible, use a software library that gives you several alternatives. Plenty of good IPC solutions are available "right out of the box." Don't waste time doing something that has already been done. You should be able to program to a high-level API, e.g. in C++, that is agnostic to exactly how the trick is done. (And definitely, IMHO, "use C++.")

Pipes are one way transfer. You can't do two way communications without the chance of deadlock.

Using pipes can be VERY slow depending on what you are doing (don't, for instance, try to pass video data through one...).

One of the slowdowns is due to the kernel having to copy data into the kernel, then copy it back
out. The larger the data, the slower it goes.

Sockets are just as fast - but is much easier to avoid deadlock, and allow for two way data transfers.

Shared memory segments are even faster (two or even three times as fast), and can be done
both directions.

I agree with the rest (well, possibly excepting C++ as it depends on what is being done).