Problem with XP scheduler?
in [Win32 Kernel]
|
From: tanix on 30 Dec 2009 13:32 In article <#PO$q9ViKHA.5604(a)TK2MSFTNGP04.phx.gbl>, "Don Burn" <burn(a)stopspam.windrvr.com> wrote: > >"tanix" <tanix(a)mongo.net> wrote in message >news:hhel75$k12$5(a)news.eternal-september.org... >> In article <emgj$XLiKHA.1824(a)TK2MSFTNGP04.phx.gbl>, "Don Burn" >> <burn(a)stopspam.windrvr.com> wrote: >>> >>>I would love to hear your definition of a "truly multitaking OS". About >>>all >>>that anyone can agree on is that a multitasking OS supports multiple >>>tasks. >>>This has been a debate for a very long time, depending on the definition >>>locking all the other processes including display is not only ok, it is >>>expected. >> >> Btw, do you realize what you did, mr. smart by top poting >> and leaving the original material AFTER you sig? > >I assume you meant top posting. Yep. > You do realize that the arguement over >bottom versus top posting is older than Usenet? It is NOT an argument of top vs. bottom. It is an argument of inserting your comment in place, in the appropriate context. So it becomes clear which exact point you are commenting on. Commenting on the whole thing in bulk is not necessarily useful. Because people that read the articles from web, via search engine, do not even know what you are commenting on. Because your comments are TOTALLY out of context. Do I have to chew things like these here on kernel level groups? :--} > It has always depended on >the user's tastes, the software doing the reading and the performance of the >connection. Nope. It depends on your brain functioning or not. > I can remember Usenet wars of 25 years ago where people were >vilified for bottom posting. What is this? Do you understand the basic argument? Why do you need to tell me such a useless stuff? >> Well, your paragraph above is ALL that is left for someone, >> who is going to find this article via web. >And how is this the case? I can go back and find whole thread for quite a >number of years, top posting versus bottom posting did nothing to them. And how long is it going to take you, if you even going to bother to go and perform a search in order to find the whole thread? Do you think what you have to say is so great that anyone is even going to bother about it enough to waste a few minutes of his time to find the whole thread and read it via some screwed up web interface? Ok, this would be enough. Looks like a hopeless case to me. "Do as thou wilt". Cya. >> So, if you do THESE kinds of screwups, what can you possibly argue >> as far as "truly multitasking OS" goes? > >Well as I presented above these are not screwups, just matter of taste. As >far as multitasking OS'es I have worked on the OS teams of a number of >systems in my career. I can remember fights on what is the desirable (no >one before you has implied that there is only one ordained) scheduling >model. They are much more varied than the arguments that were presented >here. > >> Well, for one thing, truly multitasking OS would NEVER exhibit >> such a behavior. Just imagine the IBM mainframes on Wall St. >> behaving like this? Or some major banks, or you name it? > >Actually most of the IBM schedulers did have this performance for years. I >cannot state recently since I have not used an IBM mainframe for a good >while. I do know that I could set the priority of a job such that all input >and output essentially ceased back in the days of OS 360. This was in the >era that IBM 360's and IBM 370's were the majority of business computers in >the world. This is essentially what the complaint about Windows scheduling >is about. > >> Do you realize what would happend in the world? >> On nuclear plants, public transportation system, water supply >> facilities and ALL sorts of things in the real world? > >Have you worked in ANY of these? They use operating systems where a thread >can starve the rest of the threads, for good reason. If you have a >detection of say a nuclear meltdown, you do not want the computer to be >doing anything but shutting down the system. These plants run on real-time >multitasking operating systems that have schedulers that if you are the >highest priority you own the processor until you block for something period. > >You stated in another post "Thread should NEVER be able to take the CPU time >from other threads. ALL it has is its own time slice. Period." That is a >pretty good definition of a time sharing system, but time sharing is just >one of the many types of multi-tasking operating systems that exist. > >Microsoft made some design decisions on Windows as far as the scheduler 20 >years ago when NT was started. It can be argued that these are not the >right decision now, but most people have a hard time predicting 20 years in >the future. I will point out as I said before, that changing something like >a scheduling algorithm has impacts that even if it is better for most >things, some users will be unhappy. That is why most changes are slow once >you ship an OS, change is a problem in itself. > > -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, organized by major topics of language, tools, methods, techniques.
From: tanix on 30 Dec 2009 13:43 In article <9418f497-efe8-44b9-b9ab-71fc99cf4dc7(a)j19g2000yqk.googlegroups.com>, J de Boyne Pollard <J.deBoynePollard(a)Tesco.NET> wrote: >DB> My real complaint with this whole discussion is that >DB> multitasking means different things to different people. =A0 >DB> If you are an old timer like me, there were major >DB> screams 30 years ago when Unix claimed to be >DB> multitasking. At that time most companies described >DB> what we now consider as multitasking as >DB> multiprocessing and that tasks were what we currently >DB> call threads. =A0And 30 years ago, Unix did not support >DB> threads. > >Yes (although with either definition the trolling here is false). >More fundamentally, "task" means different things to different >people. In some cases, a "task" is what in the Windows NT model would >be a "thread". In other cases, a "task" would be a Windows NT >"process". In yet other cases still, a "task" is what in the Solaris >model would be a "light weight process". Teminology is and long has >been, most definitely, an issue in this area. If one has clear >definitions of "thread", "process", and "processor", then "multi- >thread", "multi-process", and "multi-processor" have clear meanings. >But since "task" is often ambiguous, "multi-tasking" is as well. >Let's not get started on the difference between "concurrent" and >"multi-programmed" or what "job" means ... (-: Well, that is all fine and dandy. But... What it boils down to, no matter what you call it, is something that can have potentially deadly effect on operation of your entire system, and I see it all day long every day with windows. When I have at least 10 programs running and about 30 windows opened and have done several hours worth of work and click back on my firefox icon and do a refresh of about 10 pages in a rapid succession, and my box simply freezes, what it means to me is that I lost ALL sorts of work, and I lost ALL sorts of program states, and it is going to take me half an hour to restore all things, and that is if I am lucky. Some work might have been lost for good. I could care less if firefox freezes by itself but I can continue with everything else. I could simply hand kill that process from the task manager need be as I have done gazillion of times. But when I loose nothing less then OS, than it is a TOTALLY different issue, and the issue is OS, and not some screwed up firefox or some driver it happens to be using. Simple as that. -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, organized by major topics of language, tools, methods, techniques.
From: tanix on 30 Dec 2009 13:49 In article <ObYzp6WiKHA.4200(a)TK2MSFTNGP04.phx.gbl>, "Alexander Grigoriev" <alegr(a)earthlink.net> wrote: >I suggest you learn how multithreading with priorities work. >And all modern non-realtime dispatchers (Windows, Linux, etc) will happily >preempt ("take the CPU time from other threads" in your words) a thread when >higher priority thread is woken up. :--} Anything else, mr. smart? :--} Looks like you are SO great, and of such a noble blood, that you could not be bothered replying in appropriate context. :--} And YOU do the KERNEL level work? :--} >"tanix" <tanix(a)mongo.net> wrote in message >news:hhellm$k12$6(a)news.eternal-september.org... >> In article <#cJ1l6LiKHA.1460(a)TK2MSFTNGP06.phx.gbl>, "Alexander Grigoriev" >> <alegr(a)earthlink.net> wrote: >> >> First of all, why do you top post? >> Do you know what top posting means? >> >>>I think you'll agree that Windows scheduler could do better job for taming >>>runaway threads. It's pretty easy to detect such threads - if a thread >>>uses >>>up its timeslice repeatedly, >> >> Thread should NEVER be able to take the CPU time from other threads. >> ALL it has is its own time slice. >> Period. >> >>> it's running away. For such a thread, the >>>scheduler should apply penalty. >> >> First of all, the thread should not be allowed to run >> for a longer time than its alloted timeslice. >> > > -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, organized by major topics of language, tools, methods, techniques.
From: Liviu on 30 Dec 2009 14:47 "tanix" <tanix(a)mongo.net> wrote... > > Why don't you talk SUBSTANCE? Funny you'd say that, since it's _you_ who (again) skipped over the "substantive" parts of my earlier post... || If you are serious about finding/fixing the actual issue, then first || thing unplug your usb mouse, reboot into safe mode (with networking) || and see if the issue persists. Anyway, at this point it's quite obvious that you are not interested in finding or fixing anything. So as far as I am concerned you can keep happily crashing "every few days" and imagine that's a windows curse, rather than your own failure to track it down and figure it out. Liviu
From: tanix on 30 Dec 2009 20:09
In article <OaA1MkYiKHA.4672(a)TK2MSFTNGP06.phx.gbl>, "Liviu" <lab2k1(a)gmail.c0m> wrote: >"tanix" <tanix(a)mongo.net> wrote... >> >> Why don't you talk SUBSTANCE? > >Funny you'd say that, since it's _you_ who (again) skipped over >the "substantive" parts of my earlier post... > >|| If you are serious about finding/fixing the actual issue, then first >|| thing unplug your usb mouse, reboot into safe mode (with networking) >|| and see if the issue persists. > >Anyway, at this point it's quite obvious that you are not interested in >finding or fixing anything. :--} I am just fine. Thank you. Everything is in a good shape for me. Enough. > So as far as I am concerned you can keep >happily crashing "every few days" and imagine that's a windows >curse, rather than your own failure to track it down and figure it out. >Liviu > > -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, organized by major topics of language, tools, methods, techniques. |