|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
That's pretty much the same race as I have now as right now the race is just between my dropping the commandGate and calling the exit function. -- John Baldwin <email@hidden> > -----Original Message----- > From: Mike Smith [mailto:email@hidden] > Sent: Thursday, October 06, 2005 4:08 PM > To: Baldwin, John > Cc: Darwin Drivers Mailing List > Subject: Re: Making IOExitThread safe > > The thread can take a reference on your class (this->retain()) which > will prevent the unload until the reference is released. That narrows > the race down to the thread being preempted between the release > and its exit. > > = Mike > > On Oct 6, 2005, at 12:43 PM, Baldwin, John wrote: > > > So, I have a question about IOExitThread. I have a little driver > > for a > > debug serial port that used use cdevsw on Panther, but is now > > rewritten > > as a subclass of IOSerialStreamSync for Tiger. It uses one extra > > thread > > to take pop data off of the TX queue and push it to the actual > > hardware > > (the data for the RX queue arrives via interrupts). So, I create the > > thread in my driver's start() routine and send it a signal to ask > > it to > > die in my stop() routine. Is there any way that I can verify in my > > stop() routine that the thread has truly died before returning? I > > already do a hand-shake where I set a flag and to wake up the > > thread and > > then in stop() I sleep until the thread wakes up, notices the flag is > > set, and then clears it, drops its command gate and calls > > IOExitThread(). My concern is that in theory, as soon as it > > signals the > > thread in stop() and drops the command gate, the thread in stop() > > could > > resume and return to its caller, and that depending on Murhpy's Law > > type > > scheduling, the KEXT could be unloaded before the TX thread actually > > gets a chance to call IOExitThread(), and thus when that thread is > > finally resumed it would get a fault when it tried to execute code in > > the function that calls IOExitThread(). > > > > In FreeBSD I changed the kernel thread exit function (kthread_exit > > ()) to > > do an extra wakeup on the proc pointer for the kthread in question to > > allow callers to know when a thread that has been requested to die has > > truly exited their module's code section so that it is safe to > > continue > > a module unload operation. Is there anything similar that I can do > > with > > an IOThread? Does I/O Kit do some extra magic with IOThreads to keep > > track of this for me so that I don't have to handle this race? > > > > -- > > John Baldwin > > <email@hidden> > > > > > > _______________________________________________ > > Do not post admin requests to the list. They will be ignored. > > Darwin-drivers mailing list (email@hidden) > > Help/Unsubscribe/Update your Subscription: > > > > > > This email sent to email@hidden > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-drivers mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
Visit the Apple Store online or at retail locations.
Copyright © 2011 Apple Inc. All rights reserved.