From owner-freebsd-arch Tue Nov 2 20:26:42 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 84B1014C39 for ; Tue, 2 Nov 1999 20:26:36 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA02941 for ; Wed, 3 Nov 1999 05:26:35 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA84303 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 05:26:34 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 14BE714C39 for ; Tue, 2 Nov 1999 20:26:24 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id UAA16380; Tue, 2 Nov 1999 20:26:19 -0800 (PST) Date: Tue, 2 Nov 1999 20:26:18 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: Nate Williams , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: <381F85F2.BF6D5A2@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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