Date: Sun, 04 Mar 2001 13:24:00 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_intr.c src/sys/sys interrupt.h Message-ID: <XFMail.010304132400.jhb@FreeBSD.org> In-Reply-To: <200103041812.f24ICoO80977@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04-Mar-01 Justin T. Gibbs wrote: >>When an interrupt handler is removed, we mark the handler as dead if the >>thread >>is runnable. We do this with a spin lock held to prevent new interrupts from >>coming in while we do this. If the thread is runnable, then on a UP system >>the ithread isn't running. When the ithread wakes up, it has either already >>run the handler (in which case we don't care), it is running the handler, or >>it >>is about to run the handler. If it is about to run the handler, then we will >>see the IH_DEAD flag and remove the handler. If it is in the handler, >>there's >>nothing we can really do. > > Sure there is. You can block the "releaser" until the interrupt routine > exits. > There is no other way to resolve the race condition. And what if the routine that is deregeristering the interrupt handler holds a mutex that the ithread is blocked on? We will deadlock if we wait for the ithread to exit. > Since registering and de-registering interrupt handlers should be an uncommon > occurance, it would be nice to avoid having to have a spin-lock acquired just > to protect the list of handlers serviced by the ithread that needs to be > acquired > every time it is placed in the run state. Yes, this is exactly what I'm attemptint to avoid. > Perhaps you should just change the > handler's entry point to the removal function and set the ithread runable. > The > new entry point would remove the handler and wakeup the thread waiting for > the > entry to be removed. This _still_ doesn't help if we are already executing the handler. I already work around the condition this would work around with the IH_DEAD flag. But if I'm _already_ executing that handler, I can't do anything to fix that. > Something very similar could be used to add new entries onto the queue so > long > as the ithread's list of handlers has a sentinal node that usually is NULL. It uses a normal TAILQ. Since pointer updates are atomic on all archs we support atm and since we fully initialize a struct intrhand before we put it on a list so there is currently no problem there. > -- > Justin -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010304132400.jhb>