Re: [gentoo-dev] What is the fastest mechanism for ipc communication under the gentoo-sources kernel

[Dave Nellans <dnellans@cs.utah.edu>]

[-- Attachment #1: Type: text/plain, Size: 2134 bytes --]

paul has two good ideas and i'd encourage signals.  this is the type of
thing they exist for!  signals are definately not the "fastest" method
of ipc because of the os stuff they invoke, but they are the most
flexible IMO and won't waste cpu cycles because the processes can just
"wait" untill they see the appropriate signal (then you have signal
processing overhead, but thats probobly minor compared to scheduling a
process to loop indefinately on a semaphore)

just another 2 cents ;)
dave

On Tue, 2003-07-22 at 12:30, Paul de Vrieze wrote:
> On Tuesday 22 July 2003 19:07, Jeff Adams wrote:
> > Hello,
> >
> > I have a producer process that makes updates to shared memory.  I need to
> > notify consumer processes (potentially multiple) as quickly as possible.
> >
> > What I am looking for is a fast "wake-up" mechanism and a synchronization
> > mechanism so that events are not lost.
> >
> > I'm currently using semaphores as the wake up mechanism.  Question is this
> > the fastest way to do this without going into a tight loop (waste of
> > processor cycles)?
> >
> > I'd also have the issue of clients showing up asynchronously.  If I just
> > use semaphores counts based on the number of clients I run the risk of
> > missing a client.  Also if the clients process events too slowly then the
> > producer will keep incrementing the semaphore beyond the client count. 
> > Then if one client is faster than the others it may get awakened multiple
> > times for the same event.
> >
> > Any suggestions?
> >
> 
> You could use pipes as IPC. In that case you push a byte in the pipe at the 
> moment you want the clients to wake up. This should make them me scheduled as 
> soon as possible (in case they are locked waiting for the pipe). Another way 
> could be to use signals. But if you give each process a semaphore that should 
> also work. The only question is whether it is a problem if one process has a 
> slightly higher chance to be first than the other processes. Normally it 
> isn't.
> 
> Paul
-- 
Dave Nellans
http://lucy.wox.org/~dnellans/
dnellans@cs.utah.edu

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]