* [gentoo-dev] What is the fastest mechanism for ipc communication under the gentoo-sources kernel
@ 2003-07-22 17:07 Jeff Adams
2003-07-22 18:30 ` Paul de Vrieze
0 siblings, 1 reply; 4+ messages in thread
From: Jeff Adams @ 2003-07-22 17:07 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-dev] What is the fastest mechanism for ipc communication under the gentoo-sources kernel
2003-07-22 17:07 [gentoo-dev] What is the fastest mechanism for ipc communication under the gentoo-sources kernel Jeff Adams
@ 2003-07-22 18:30 ` Paul de Vrieze
2003-07-23 3:43 ` Dave Nellans
0 siblings, 1 reply; 4+ messages in thread
From: Paul de Vrieze @ 2003-07-22 18:30 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-dev] What is the fastest mechanism for ipc communication under the gentoo-sources kernel
2003-07-22 18:30 ` Paul de Vrieze
@ 2003-07-23 3:43 ` Dave Nellans
2003-07-23 14:13 ` wes chow
0 siblings, 1 reply; 4+ messages in thread
From: Dave Nellans @ 2003-07-23 3:43 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-dev] What is the fastest mechanism for ipc communication under the gentoo-sources kernel
2003-07-23 3:43 ` Dave Nellans
@ 2003-07-23 14:13 ` wes chow
0 siblings, 0 replies; 4+ messages in thread
From: wes chow @ 2003-07-23 14:13 UTC (permalink / raw
To: Dave Nellans; +Cc: gentoo-dev
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-07-23 14:13 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-07-22 17:07 [gentoo-dev] What is the fastest mechanism for ipc communication under the gentoo-sources kernel Jeff Adams
2003-07-22 18:30 ` Paul de Vrieze
2003-07-23 3:43 ` Dave Nellans
2003-07-23 14:13 ` wes chow
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox