Date: Thu, 26 Apr 2001 19:10:57 -0500 From: Mike Meyer <mwm@mired.org> To: Terry Lambert <tlambert@primenet.com> Cc: herveyw@dynamic-cast.com (Hervey Wilson), markgiglio@yahoo.com (Mark Giglio), chat@FreeBSD.ORG Subject: Re: hotmail converted from freeBSD Message-ID: <15080.47377.734245.834332@guru.mired.org> In-Reply-To: <200104261739.KAA24045@usr05.primenet.com> References: <15080.15992.732520.463161@guru.mired.org> <200104261739.KAA24045@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert <tlambert@primenet.com> types: > > Actually, the first one was pretty much what I was looking for - at > > least at this level. It looks like completion ports give you a way to > > tune behavior between the single thread w/select and the > > thread-per-socket model, which is an interesting concept. The real use > > is to adopt the single thread w/select model to an SMP system. The > > recommended tuning on a uniprocessor system is a single thread. > > > > The only thing that the completion port model clearly saves you > > compared to the thread-per-socket model is memory resources. It may > > save you context switches compared to some approaches, but that looks > > to be more of a problem with the underlying platform than anything > > else. > > > > It does add the problems of dealing with threading to the single > > thread w/select model. That's pretty much the cost of using more than > > one CPU, though. > > > > In theory, the Unix select & thread semantics can generate this kind > > of behavior. I'd be surprised if it actually worked that well, > > though. I'd *not* be surprised if it failed in some strange way. > > The reasoning behind I/O completion ports is that it permits > you to do something on completion of I/O, such as initiate yet > another I/O (a "feedme" signal that is delivered reliably as an > event, unlike a UNIX signal, which is merely a persistant > condition). The author of the paper I referenced mentions that, but goes on to state that what IO completions ports provide that some other Windows facility doesn't is the ability to control how many threads are actively dealing with the results of IO going through that port. > If you look at the FreeBSD threads design, it doesn't suffer from > these problems (barring the "KSEG == CPU affinity" silliness that > pops up in discussion on -arch occasionally). > > This _significantly_ saves on context switch overhead; in particular, > it avoid reloading of control register 3, and TLB shootdown, which > would otherwise result in significant processing overhead, even > when switching between threads in the same group (since you can > never know what thread the scheduler is going to pick, only that > you are being preempted). The author listed two savings over the "thread per socket" model: one was the memory resources used by that number of threads, and the other was the context switch overhead. I couldn't see why you would get a lot of context switch savings on a properly designed system. Glad to see FreeBSD is such a system. > For more information on threading in Microsoft Windows, I suggest > you sign up as an MSDN developer, after which they will provide > you with much more documentation than they provide you on their > web site. If you can get them to send it to you, you might also > ask for their threading architecture model for their Active Server > Platform (at the time I saw it, it was still named "VIPER"). You > may also want to read _all_ of the documents on their web site that > discuss "rental model", "apartment model", and "freethreading model" > threaded application, and the increasing restrictions on how you > must program for each of them. Taken together, these documents > will give you a basic overview from which you can deduce a lot of > their internal architecture. While I appreciate the suggestion, I'm not going to follow up on it. If I ever find myself in a situation where the only income I can get programming involves working with Windows, I'll start selling used cars for a living. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15080.47377.734245.834332>