Date: Sun, 04 Mar 2001 14:51:06 -0700 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: John Baldwin <jhb@FreeBSD.org> 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: <200103042151.f24Lp6O83223@aslan.scsiguy.com> In-Reply-To: Your message of "Sun, 04 Mar 2001 13:24:00 PST." <XFMail.010304132400.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103042151.f24Lp6O83223>