kthread_exit(9) unexpectedness
Lawrence Stewart
lstewart at freebsd.org
Thu Nov 20 14:22:06 PST 2008
John Baldwin wrote:
> On Wednesday 19 November 2008 08:21:44 am Lawrence Stewart wrote:
>> Hi all,
>>
>> I tracked down a deadlock in some of my code today to some weird
>> behaviour in the kthread(9) KPI. The executive summary is that
>> kthread_exit() thread termination notification using wakeup() behaves as
>> expected intuitively in 8.x, but not in 7.x.
>
> In 5.x/6.x/7.x kthreads are still processes and it has always been a wakeup on
> the proc pointer. kthread_create() in 7.x returns a proc pointer, not a
> thread pointer for example. In 8.x kthreads are actual threads and
Yep, but the processes have a *thread in them right? The API naming is
obviously slightly misleading, but it essentially creates a new single
threaded process prior to 8.x.
> kthread_add() and kproc_kthread_add() both return thread pointers. Hence in
Yup.
> 8.x kthread_exit() is used for exiting kernel threads and wakes up the thread
> pointer, but in 7.x kthread_exit() is used for exiting kernel processes and
> wakes up the proc pointer. I think what is probably needed is to simply
In the code, yes. Our documented behaviour as far as I can tell is
different though, unless we equate a "thread handle" to "proc handle"
prior to 8.x, which I don't think is the case - they are still different.
> document that arrangement as such. Note that the sleeping on proc pointer
I agree that the arrangement needs to be better documented. The change
in 8.x is subtle enough that reading the kthread man page in 7.x and 8.x
doesn't immediately make it obvious what's going on.
> has been the documented way to synchronize with kthread_exit() since 5.0.
>
Could you please point me at this documentation? I've missed it in my
poking around thus far.
Cheers,
Lawrence
More information about the freebsd-arch
mailing list