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

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

[Jeff Adams]

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?

Thanks in advance!




--
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1533 bytes --]

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

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Dave Nellans]

[-- 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 --]

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

[wes chow]

Actually, I'd really start to question the application's realtime 
requirements if you start favoring one form of IPC over the other because 
of slight performance differences.  My advice is to use the mechanism 
that's going to require the least amount of maintenance, ie the cleanest 
design.  Generally, programmer time is more valuable than processor time.

Wes

--
gentoo-dev@gentoo.org mailing list