Date: Thu, 19 Apr 2007 18:26:37 -0700 From: Julian Elischer <julian@elischer.org> To: Andy Jones <andjones@gmail.com> Cc: freebsd-threads@freebsd.org Subject: Re: Question about kse_switchin and TD_CAN_UNBIND Message-ID: <462816CD.3000101@elischer.org> In-Reply-To: <86992cb10704191706p1f7fbc87mc08d0b661b90a15e@mail.gmail.com> References: <86992cb10704191706p1f7fbc87mc08d0b661b90a15e@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Andy Jones wrote: > I'm curious about the meaning of the TDP_CAN_UNBIND flag being set on a > thread (in its td_pflags) (see sys/proc.h). What does it mean that a thread > "can unbind"? Second, why it is important that it is not set in > kse_switchin > (see kern/kern_kse.c) . (The answer to second question will probably become > obvious with the answer to the first). Firstly the names may be slightly misleading as the flags have remained even though the underlying implementation changed. TDP stands for TD (thread) (Private flag)_ CAN_UNBIND. Private means that no other thread should change this flag so it need not be locked. "CAN_UNBIND" indicates that when this thread entered the kernel, all the conditions were met to allow this thread to sleep waiting for some resource, and for it's upcall context structure (struct upcall) should be given to a new thread, so that another user thread could be run in its place. If this is not set then no replacement thread is sent to userland to continue working in the place of this sleeping thread, and the process as a whole will lose the use of one CPU (If it only ha sone CPU it will be stopped) until the thread wakes up again. It IS sometimes not set deliberatly. For example, when there are no more runnable user threads, the User Thread Scheduler (UTS) will sleep (actually do a kse_release()) in a way that disables the returning thread. (Since it has no work for it to do). The "UNBIND" in question is the detaching of the upcall structure from the thread. The upcall structure contains all the information and needed for the kernel thread to return to userland, and one could consider that being bound to it is a requirement for the user thread to proceed back to user space when it has woken up. If it doesn't have it when it wakes up, it will "piggy back" to user space on another thread, by dint of having its context written back to user space. The Userspace Thread Scheduler will then run it when another thread yields the processor, or returns from the kernel, and notices that the original thread has completed. A thread that does not have all the prerequisites for unbinding from its upcall structure "CAN NOT UPCALL" (hence the name), and so it will jsut sleep as per normal, keeping its upcall structure with it, so that the process as a whole loses the use of it. Each "Upcall" structure defines a UTS context that the kernel knows about, that can be used to run a user thread. All this is of course only true for KSE (M:N) threading. > > -andy jones > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?462816CD.3000101>