Advice on an IPC mechanism

Op Thu, 17 Sep 2009 15:49:11 +0200 schreef fatbald1 :

If you're concerned about latency, then maybe Linux is not for you.

In embedded software engineering, it is not uncommon to use a modern RTOS that natively provides an efficient, fast and lightweight IPC mechanism like direct asynchronous message passing.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)

t

=A0

=A0

om/mail/

Thanks for your reply. I have left out a lot of details from my original post, but we have to use Linux, an RTOS is not an option. Unfortunately I'm now being asked to pick up the pieces of a disasterous product from a software architects wet dream, and its turning out to be a real nightmare :)

Sure if it was easy it wouldn't be a challenge.

RW

I've had good results with SysV IPC: msgget, msgsnd, msgrcv calls. It deals in application-defined binary packets, so it's pretty lightweight, although programmer-intensive. It was fast enough for our app, so we didn't benchmark against alternatives. It is not very fault-tolerant, in that a process that fails to pick up its messages will bring down the whole queue. For chat between the core processes of our app this can't happen until the app has already crashed (due to a core process failing) so we put up with it.

For IPC with non-core processes we've used named pipes with success. Sockets would seem to be a good choice too.

Mel.

I would have to agree. There are just *so* many issues that can (will?) bite you in the *ss down the road. (Note that this isn't just Linux's fault -- any desktop OS will have similar hazards). Is all of your application memory wired down? What if an application has to be swapped in/out at just the same time that some "critical event" comes along? Do you even have any way of *knowing* that you've been screwed? Or, do you just wonder why there are "intermittent, non-repeatable failures" that show up from time to time?

*If* I was stuck working in such an environment (Linux), I would make sure *every* unessential process was killed off. I'd stick all of the cooperating processes into a single process container (i.e. as *threads*) and let them communicate via shared memory, queues, etc. protected with mutexes/monitors. In which case, the OS really isn't providing *any* real services for you :-/

Right tool for the Right job.

Look at the Real Time Kernel for Linux from Wind River Now part of Intel.

We have used it on several instruments for hard real time control in the microsecond range and it works well.

-- Marco UCO Lick Observatory Laboratory for Adaptive Optics

Thanks for your reply. I have left out a lot of details from my original post, but we have to use Linux, an RTOS is not an option. Unfortunately I'm now being asked to pick up the pieces of a disasterous product from a software architects wet dream, and its turning out to be a real nightmare :)

Sure if it was easy it wouldn't be a challenge.

RW

Hi All,

Many thanks for all your advice and comments, you've confirmed my suspicions on the value of Linux in this domain, and helped me come to a better understanding of my IPC standpoint.

Regards

RW

I'm not an expert, so treat all of this as pointers for you to do research:

There are open-source real-time Linux kernels available (Xandros???) -- they may or may not be snarled up in patent issues, but if you can get one free and clear, and if you don't mind seriously changing your Linux distro it may be the right answer.

The last time I was paying attention (a couple of years ago), _most_ real- time Linux distros _didn't_ make Linux into an RTOS -- instead, they ran Linux as one task belonging to an RTOS, and if you wanted real-time you had to talk to the RTOS, not Linux. Depending on how many processes you have that need real-time behavior you may or may not be screwed.

I have also _heard_ that the core Linux group is trying to make Linux "more real time", whatever the heck that means. It probably means that you can coerce the system into not violating deadlines, usually, at the cost of always avoiding applications that use the parts of the OS that just can't be made real-time yet.

--
www.wescottdesign.com

I believe that's a fair summary. "Real time" means different things to different people, and depends on the project. There are times when "real time" is an absolute - your system must respond to a given event in a given time frame, or it doesn't work. For such "hard real time" systems, the Linux kernel is unsuitable (it is unsuitable at the moment, and probably never will be). Very few "large" systems would be suitable

- the bigger the system is, the harder it is to be sure of its limits and guarantees. "Hard real time Linux" systems are always a small hard real time OS running Linux as a low priority task.

There are also times when missing a deadline is a minor problem if it doesn't happen often - a video system that drops a frame on a rare occasion, for example. A great many "real time" systems fall into this broad category, such as anything with networks that have error detection and retries. The Linux kernel has support for such "soft real time" response. Of course, you must carefully characterise and test your requirements and the system performance.