Date: Fri, 27 Apr 2001 17:49:48 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mwm@mired.org (Mike Meyer) Cc: tlambert@primenet.com (Terry Lambert), herveyw@dynamic-cast.com (Hervey Wilson), markgiglio@yahoo.com (Mark Giglio), chat@FreeBSD.ORG Subject: Re: hotmail converted from freeBSD Message-ID: <200104271749.KAA01700@usr07.primenet.com> In-Reply-To: <15080.47377.734245.834332@guru.mired.org> from "Mike Meyer" at Apr 26, 2001 07:10:57 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. The author is naieve, or is simplifying the situation intentionally. Are you in the Bay Area? I have full Microsoft documentation of the "VIPER" framework, which I could show you, but could not let you copy. You can abuse it that way, certainly, but you are doing so only in order to avoid properly marshalling objects. It turns out in the Windows model, that the virtual address spaces per thread are actually "copy on write". This effectively means that if thread "A" uses some thread local storage (all COM and DCOM objects are instances in thread local storage), and then thread "A" created thread "B", than all of the objects previously instanced in thread "A" thread local storage are accessible in thread "B", without explicit marshalling. This is not often talked about, since thread "A" could run as ADMIN, and thread "B" could do an "impersonate" prior to opening up a network connection, and you would then erroneously believe that you could only damage heap information, not instance information, if you were a malicious attacker who caused a buffer overflow in thread "B". AFAIK, there have been no attacks against NT or 2000 servers which take advantage of this, since it's really obscure, but IIS makes extensive use of this fact to avoid the need to do unnecessary marshalling, as do products from sufficiently clueful third parties. This is one of the thousands of reasons it's very hard for those companies hiring lower end talent to compete with those companies that spend the big buck on higher end, seriously clueful talent. So this "advantage" doesn't wash: I can get the same thing without completion ports by controlling my instancing and thread creation ordering, and simply knowing what the hell I am doing, instead of groping blindly based on assumption, rather than knowledge, of how things actually work. > > 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. The reason you can't get the savings on many systems is that it is nearly impossible to implement a scheduler which "perfers" a thread that doesn't require a TLB shootdown (change in virtual address space) over one that does, without shooting yourself in the foot, or strongly controlling your applications, to the point of not allowing third party code on your platform. The closest you can get is implementation of scheduler reservations -- the scheduler equivalent of implenting Djikstra's "Banker's Algorithm" as a means of livelock starvation of quantum avoidance. It turns out that Djikstra's Algorithm, if you've never heard of it, is massively conservative, to the point of commiting resources that never get consumed, but must be available "in case they are needed, since they may be needed". The only way to deal with this correctly is to decide that affinity is not a problem for the scheduler to resolve, but is instead an issue of negaffinity -- the "desire" of threads in a single thread group to run on different CPUs, and only to run on the same CPU if there is no other choice, or if overall load conditions dictate that that's a good decision. Thus the decision becomes one, not of when to schedule globally, but of when to migrate a process from the run queue of one CPU to another, due to overall run queue quantum load relative to the target run queue. NT doesn't quite achive this; their does v8 of Solaris. [ ... where to go to learn more about Windows ... ] > 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. Not to be unkind, but I think that the reference book on Windows and threads that you have been quoting is probably no good. If nothing else, you should probably not trust it enough to influence your posts on public mailing lists. Experience is a better teacher, second only to the horse's mouth. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200104271749.KAA01700>