Date: Tue, 02 Nov 1999 19:46:42 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Nate Williams <nate@mt.sri.com> Cc: Julian Elischer <julian@whistle.com>, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) Message-ID: <381F85F2.BF6D5A2@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> <199911030016.RAA26726@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote: > > [ 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. The application decides what threads are bound to kernel threads. It can bind as many threads as it wants (within process limits) to kernel threads. It need not bind them all unless it wants to. > > > 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. No, I didn't either, but you can still get the same thing by manually coding each routine. You could also set flags instead with not too much more overhead. > > 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. This is really only a concern in the threads library implementation where you are using internal resources such as spinlocks or mutexes to protect scheduling queues, file descriptor lock tables, etc. The threads library would be coded to prevent calling blocking system calls while holding such resources. All other (visible) resources are the responsibility of the application. > 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. Well, stick with what you know then ;-) And also make sure whatever we do gets sufficiently documented! > 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.... :-) 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?381F85F2.BF6D5A2>