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
