Date: Tue, 2 Nov 1999 20:26:18 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "Daniel M. Eischen" <eischen@vigrid.com> Cc: Nate Williams <nate@mt.sri.com>, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) Message-ID: <Pine.BSF.4.10.9911022007450.3260-100000@current1.whistle.com> In-Reply-To: <381F85F2.BF6D5A2@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I don't know about the rest of you but I'm busy reading :-) this thread is NOT dead ... :-) (just in case anyone thought that..) julian On Tue, 2 Nov 1999, Daniel M. Eischen wrote: > 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?Pine.BSF.4.10.9911022007450.3260-100000>