Date: Wed, 24 Jul 2002 09:05:10 -0700 From: Alfred Perlstein <bright@mu.org> To: Jay West <jwest@classiccmp.org> Cc: freebsd-hackers@freebsd.org Subject: Re: SysV IPC message queues performance Message-ID: <20020724160510.GQ77219@elvis.mu.org> In-Reply-To: <008901c23322$cdf0f320$9701a8c0@HPLAPTOP> References: <008901c23322$cdf0f320$9701a8c0@HPLAPTOP>
next in thread | previous in thread | raw e-mail | index | archive | help
* Jay West <jwest@classiccmp.org> [020724 08:01] wrote: > > I'm writing a rather major project under FreeBSD, and making fairly heavy > use of SYSV message queues so that multiple processes can communicate. I am > finding the response times for round trip message delivery between two given > processes to be pretty horrid, typically about .5 to 1 second per message > set (send query from process A to process B, then process B sends a response > back to process A and process A displays the response). This sounds like an application programming error, I find it hard to believe that you'd see such a horrid delay if things were set up properly. From reading below what appears to be happening is that your busy looping is causing the stalls, not FreeBSD. > I stripped down the code in two programs to help isolate the problem. The > basic gist is the main process (A) forks a child (B). Process A prompts for > a line of input from the keyboard. Each line that it gets, it puts on the > message queue with a target ID of process B. Process A then does a timed > wait using IPC_NOWAIT in a clock time loop for up to 5 seconds, looking for > a response from process B. When it finds a message on the queue it prints it > on the console and then goes back to the "wait for terminal input" loop. > When process B fires up, it constantly loops checking the message queue with > IPC_NOWAIT and no clock time loop - just constantly scanning. When it sees a > message for it (with the process B pid), it gets the message and then > immediately puts a constant "OK" response message on the queue targeted at > it's ppid. This is a tight loop, constantly running. This is a bad idea (busy looping). :) Why don't you use signals to tell the other process when there is data on the queue? Why are you busy waiting? Why not just use an auxiallry process to block on the queues for you or something? You might want to consider using named pipes because you can select(2) or even kevent(2) on those and get rid of your busy loop. > As a side note - the code for process B that sits there constantly scanning > the message queue with IPC_NOWAIT, this seems to be a huge waste of cpu > time. On some platforms I have seen a system call for "release quantum", > which basically is put in tight loops to keep a process from hogging the cpu > (release remainder of the timeslice). Does this mentality apply to freebsd, > and is there such a call? see the sched_yield(2) syscall. -- -Alfred Perlstein [alfred@freebsd.org] [#bsdcode/efnet/irc.prison.net] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020724160510.GQ77219>