Date: Tue, 02 Nov 1999 18:55:23 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Nate Williams <nate@mt.sri.com>, Julian Elischer <julian@whistle.com>, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) Message-ID: <381F79EB.F4D206B6@vigrid.com> References: <Pine.BSF.4.10.9911020810090.2283-100000@current1.whistle.com> <19991102173736.9E34E1FCD@io.yi.org> <199911022319.QAA26200@mt.sri.com> <381F78AF.D5073BFB@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Daniel M. Eischen" wrote: > > It could also take many kernel wakeups for a heavy I/O bound thread to > leave the kernel. I thought of this ;-). > > This is how binding a thread to a LWP can be useful. For a thread bound > to a LWP, you only notify the user level threads library if it blocks because > it's time quantum expired (so the threads library can see if it is in a > critical region). If the thread blocks due to a tsleep or something like > that, you can assume it's not holding any critical resources that the user > threads library implementation needs. In this case, you don't notify the > threads library. > > So by extending SA to allow binding threads to LWPs, you can achieve just > about the same thing as async call gates. But it's the application that gets > to decide exactly how to use these features, and not left to the implementation > in the kernel. Sorry, there I go again using LWP. Please replace LWP with Nate's chosen terminology 'kernel thread'. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?381F79EB.F4D206B6>