From owner-cvs-all Sun Mar 4 13:51:14 2001 Delivered-To: cvs-all@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 6605837B719; Sun, 4 Mar 2001 13:51:07 -0800 (PST) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f24Lp6O83223; Sun, 4 Mar 2001 14:51:06 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200103042151.f24Lp6O83223@aslan.scsiguy.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: John Baldwin Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_intr.c src/sys/sys interrupt.h In-Reply-To: Your message of "Sun, 04 Mar 2001 13:24:00 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Mar 2001 14:51:06 -0700 From: "Justin T. Gibbs" Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> 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. That is a driver bug or a bug in the deregistering mechanism. There shouldn't be a need for that code to hold any locks after it has decided whether to accept the detach and during the removal of the interrupt handler. >> 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. Sure it does. Once the new handler is run, you are guaranteed that the old handler is not running and can cannot be run again. If the handler is running, the new handler will not be run until the next time through the ihandler list. The trick is making sure that the ithread loops at least one more time. So, if you sleep until the your new handler is run, you are always safe. >> 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. How do you avoid the race when two threads attempt to add onto the list at the same time? A single atomic store doesn't help you unless you can safely test and recover from a colision. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message