Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!nx01.iad01.newshosting.com!newshosting.com!198.186.194.249.MISMATCH!transit3.readnews.com!news-out.readnews.com!transit4.readnews.com!panix!panix5.panix.com!not-for-mail From: jeffj@panix.com (Jeff Jonas) Newsgroups: comp.os.linux.embedded Subject: Re: Message Queue for high performance system Date: 1 Sep 2011 22:44:18 -0400 Organization: Jeff's House of Electronic Parts Lines: 18 Message-ID: References: NNTP-Posting-Host: panix5.panix.com X-Trace: reader1.panix.com 1314931458 22880 166.84.1.5 (2 Sep 2011 02:44:18 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Fri, 2 Sep 2011 02:44:18 +0000 (UTC) Xref: x330-a1.tempe.blueboxinc.net comp.os.linux.embedded:43 In article , Raj wrote: >We are planning to use around 100 message queues in a high performance >system for IPC. And the messages used are of fewer bytes in sizes. >Would like to know if there any limitations or caveats in using Linux >IPC message queues. Old *nix systems required static allocation of message queues: number of queues, number of entries, etc. Is this system using any networking? Unless you're using message priorities and out-of-band-signalling, sockets do the job well and tend to have better dymanic buffering/allocation. I never did the benchmarking but several places I worked used shared memory & semaphores instead of message queues, claiming it was faster.