From owner-cvs-all Sun Mar 4 13:24:49 2001 Delivered-To: cvs-all@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id C1D5737B719; Sun, 4 Mar 2001 13:24:19 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@dhcp152.geekhouse.net [192.168.1.152]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f24LPA183715; Sun, 4 Mar 2001 13:25:10 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200103041812.f24ICoO80977@aslan.scsiguy.com> Date: Sun, 04 Mar 2001 13:24:00 -0800 (PST) From: John Baldwin To: "Justin T. Gibbs" Subject: Re: cvs commit: src/sys/kern kern_intr.c src/sys/sys interrupt.h Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 -- 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