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