From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17555 invoked by uid 1002); 23 Jul 2003 03:43:50 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 27822 invoked from network); 23 Jul 2003 03:43:50 -0000 From: Dave Nellans Reply-To: dnellans@cs.utah.edu To: gentoo-dev@gentoo.org In-Reply-To: <200307222031.01286.pauldv@gentoo.org> References: <200307222031.01286.pauldv@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3lUmyiSzv0VrcFdliyAO" Organization: U of Utah Message-Id: <1058931820.23552.4.camel@malfus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 22 Jul 2003 21:43:41 -0600 Subject: Re: [gentoo-dev] What is the fastest mechanism for ipc communication under the gentoo-sources kernel X-Archives-Salt: 58a45e74-08d9-4837-bfeb-a63d88cd3958 X-Archives-Hash: fb17f6bde544e9a856c7806fc248dfb3 --=-3lUmyiSzv0VrcFdliyAO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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 synchronizati= on > > mechanism so that events are not lost. > > > > I'm currently using semaphores as the wake up mechanism. Question is t= his > > 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 jus= t > > 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 t= he > > producer will keep incrementing the semaphore beyond the client count.=20 > > Then if one client is faster than the others it may get awakened multip= le > > times for the same event. > > > > Any suggestions? > > >=20 > You could use pipes as IPC. In that case you push a byte in the pipe at t= he=20 > moment you want the clients to wake up. This should make them me schedule= d as=20 > soon as possible (in case they are locked waiting for the pipe). Another = way=20 > could be to use signals. But if you give each process a semaphore that sh= ould=20 > also work. The only question is whether it is a problem if one process ha= s a=20 > slightly higher chance to be first than the other processes. Normally it=20 > isn't. >=20 > Paul --=20 Dave Nellans http://lucy.wox.org/~dnellans/ dnellans@cs.utah.edu --=-3lUmyiSzv0VrcFdliyAO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/HgRrdtkLPRim+bkRAlUZAJ0VA8bklaVj74lZEoYTQOImNxUCPgCfVhUS E5pTmhRb1J+dOzXVdiA8H20= =aVN6 -----END PGP SIGNATURE----- --=-3lUmyiSzv0VrcFdliyAO--