Date: Tue, 2 Nov 1999 17:16:12 -0700 From: Nate Williams <nate@mt.sri.com> To: "Daniel M. Eischen" <eischen@vigrid.com> Cc: 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: <199911030016.RAA26726@mt.sri.com> In-Reply-To: <381F78AF.D5073BFB@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
[ My assertion that Scheduler Activations isn't a good solution for heavy I/O applications ] > > What am I missing? Is it just a fact that there is no good threading > > solution for this kind of application? Solaris seems to do a pretty > > good job of optimizing this case, although it may be that we have > > nothing better to compare it to simply because no one has implemented a > > robust enough implementation on any other OS/hardware platform? > > 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. [ I'm assuming that LWP == kernel thread ] Then we're no longer using SA, and we're more like the Solaris model, as I understand it. At this point, you'd have *LOTS* more threads than available processors, because it is expected to have lots of LWP's blocked in the kernel. > 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). They talk about this in the paper, and I don't like their solution. Having to modify the compiler/assembler and such is not a workable solution, IMO. > 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. Maybe, maybe not. It still might be holding onto a critical resource that it obtained while in userland. /* Only allow the one thread to modify the shared buffer */ aquire_critical_resource(); read(); release_critical_resource(); Granted, my example is a bad design if I'm expecting the read call to block, but I'm sure there are good designs that may still use this, especially in the case where *most* of the time the thread won't block, so it allows you to optimize the common case. > 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. The idea of being 'too flexible' scares me. Writing correct threaded code is hard, when you start throwing in the complexity of determining thread scheduler models, types of threads to create, etc..., and all of a sudden multi-process solutions start to look pretty good. My reason for writing multi-threaded code is more often ease of implementation and maintainability. When something is easier to implement, it also tends to be more effecient, since you can spend more time 'optimizing' it, instead of spending all of your time making it correct. But, that's a personal soapbox, and may not be appropriate for FreeBSD.... Nate 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?199911030016.RAA26726>