Problem with XP scheduler?
in [Win32 Kernel]
|
From: tanix on 29 Dec 2009 23:41 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. No thread, under ANY circumstances should eat ALL of your cpu time, no matter what. Even if it deadlocks or runs in some dead loop. > Even if it's REALTIME_PRIORITY. There is no >reason a realtime thread should be CPU-intensive; if it is, it should be >demoted automatically. Well, most of it looks like a bad design or architecture to me. But no thread should be able to drastically impact the most critical supervisory threads that manage the most critical aspects of the system, such as mouse or keyboard on the windows. No matter how screwed up your device driver is, it should NEVER, under ANY cicrumstances be able to cause total look of your system. First of all, it is a DISASTER security wise. Secondly, when your system appears non responsive and some processes are still running, what does THAT mean? Well, it means your system would not pass a SINGLE security test suite. Ok, enough. I really have no time to waste on these usless discussions, full or arrogance of "holier than thouh", pronounced by those, who are in fact not. >In the current state, a couple of runaway Internet Explorer windows can >severely impact system responsiveness, to the point it's almost impossible >to switch a session. And fricking DDE broadcasts don't make it better, too. >I wish DDE died away. > >That said, if a videodriver wedges up (which would produce an infamous 0xEA >THREAD_STUCK_IN_DEVICE_DRIVER bugcheck), then it's IHV's fault. > >"Don Burn" <burn(a)stopspam.windrvr.com> wrote in message >news:emgj$XLiKHA.1824(a)TK2MSFTNGP04.phx.gbl... >>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. >> >> >> -- >> Don Burn (MVP, Windows DKD) >> Windows Filesystem and Driver Consulting >> Website: http://www.windrvr.com >> Blog: http://msmvps.com/blogs/WinDrvr >> Remove StopSpam to reply >> >> >> >> "tanix" <tanix(a)mongo.net> wrote in message >> news:hhdfs1$1it$8(a)news.eternal-september.org... >>> In article <hhcoup$8am$1(a)atlantis.news.neostrada.pl>, >>> =?ISO-8859-1?Q?Grzegorz_Wr=F3bel?= >>> </dev/null(a)localhost.localdomain> wrote: >>>>Tim Roberts wrote: >>>>> Grzegorz Wr�bel </dev/null(a)localhost.localdomain> wrote: >>>>> >>>>>> Tim Roberts wrote: >>>>>>> Get real. A software problem cannot cause your machine to lock up so >>>>>>> hard >>>>>>> that even mouse and keyboard stop. >>>>>> Get rational. User mode app can lock up mouse and keyboard just by >>>>>> starving system processes that manage mouse and keyboard input. On the >>>>>> single CPU/core machines it was very common to happen. On the multi >>>>>> core >>>>>> machines much less likely to happen "naturally", but still possible. >>>>> >>>>> No. A user mode app can certainly prevent other user mode apps from >>>>> processing mouse and keyboard input, yes, but the mouse pointer keeps >>>>> moving, and pressing the caps lock key still toggles the caps lock >>>>> indicator. Stopping those requires the "assistance" of kernel code. >>>> >>>>No. The point is you can lock mouse and keyboard to the point that the >>>>mouse cursor stops moving and no other application (including Windows >>>>shell) can receive/process mouse and keyboard input. >>> >>> ONLY in not truly multitasking OS. >>> >>>>This is known issue, if you have never experienced it as a programmer, >>>>you still can read about it in MSDN: >>>>http://msdn.microsoft.com/en-us/library/ms685100(VS.85).aspx >>> >>> You can read all you want. >>> >>> Enough of this. >>> >>>>You can of course argue this is still "kernel code" that freezes the >>>>box, but such argumentation doesn't have much sense since this code is >>>>executed directly by user mode API calls. >>>> >>>> >>>>This is the sample test code I once wrote to effectively freeze the >>>>single CPU/core Windows box for 30 seconds (on post XP system you'll >>>>need to run it elevated otherwise SetPriorityClass() will fail): >>>> >>>>//lockme.cpp >>>> >>>># include <windows.h> >>>># include <math.h> >>>> >>>>int main() >>>>{ >>>> int i,j,k; >>>> double a,b,c; >>>> ULARGE_INTEGER start,current; >>>> SYSTEMTIME st; >>>> FILETIME ft; >>>> >>>> SetPriorityClass(GetCurrentProcess(),REALTIME_PRIORITY_CLASS); >>>> >>>> SetThreadPriority(GetCurrentThread(),THREAD_PRIORITY_TIME_CRITICAL); >>>> >>>> GetSystemTime(&st); >>>> SystemTimeToFileTime(&st,&ft); >>>> memcpy(&start,&ft,sizeof(ft)); >>>> >>>> for(;;){ //lets do some heavy computation; >>>> c = 0.9; >>>> a = sin(c); >>>> b = cos(c); >>>> c = log(pow(a,b)+c); >>>> k = int(c)+5; >>>> j = 4*k*k*k + 2*k*k + k + 1; >>>> >>>> GetSystemTime(&st); >>>> SystemTimeToFileTime(&st,&ft); >>>> memcpy(¤t,&ft,sizeof(ft)); >>>> if(current.QuadPart-start.QuadPart>300000000) // release >>>> the >>>> lock >>>>after 30 seconds >>>> break; >>>> } >>>> >>>> return 0; >>>>} >>>> >>>> >>>>The above code simply sets its base priority to 31 and then occupy CPU. >>>> >>>>Haven't tried it on multicore box, but presumably if you run it from >>>>elevated console n times (when n is number of the CPU cores) you should >>>>freeze the box too. Unless OS tries to reserve one core for itself >>>>(unlikely). >>>> >>>> >>> >>> -- >>> 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. >>> >>> >>> __________ Information from ESET NOD32 Antivirus, version of virus >>> signature database 4726 (20091229) __________ >>> >>> The message was checked by ESET NOD32 Antivirus. >>> >>> http://www.eset.com >>> >>> >>> >> >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus >> signature database 4726 (20091229) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> >> > > -- 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 29 Dec 2009 23:46 So, you, "kernel level" "holier than thoug" arrogant fools, are ALL top posting here? :--} What a joke. I could not be bothered. It is taken totally out of context. And I could care less how "great" you are. To me, you are simply fools. In article <uKsOUJNiKHA.3964(a)TK2MSFTNGP06.phx.gbl>, "Paul Baker [MVP, Windows Desktop Experience]" <paulrichardbaker(a)community.nospam> wrote: > >I totally agree with your disdain for DDE. If I understand it correctly, and >I may not because I really don't care about or *want* to understand DDE, it >blocks the client until all top-level windows respond or it times out, even >if they are not the target! And so DDE is in effect allowing a hanging >process to cause other user processes to hang as well. > >From what I have read, the only reason that Internet Explorer uses DDE is >because it was that way in the original code purchased from NCSA which they, >in turn, licensed from Spyglass! > >Someone is probably relying on DDE, whereas they should be using >ShellExecuteEx and have the shell figure out how to open a URL. The shell >would then run Internet Explorer using a command line. > >Paul > >"Alexander Grigoriev" <alegr(a)earthlink.net> wrote in message >news:%23cJ1l6LiKHA.1460(a)TK2MSFTNGP06.phx.gbl... >>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, it's running away. For such a thread, the >>scheduler should apply penalty. Even if it's REALTIME_PRIORITY. There is no >>reason a realtime thread should be CPU-intensive; if it is, it should be >>demoted automatically. >> >> In the current state, a couple of runaway Internet Explorer windows can >> severely impact system responsiveness, to the point it's almost impossible >> to switch a session. And fricking DDE broadcasts don't make it better, >> too. I wish DDE died away. >> >> That said, if a videodriver wedges up (which would produce an infamous >> 0xEA THREAD_STUCK_IN_DEVICE_DRIVER bugcheck), then it's IHV's fault. >> >> "Don Burn" <burn(a)stopspam.windrvr.com> wrote in message >> news:emgj$XLiKHA.1824(a)TK2MSFTNGP04.phx.gbl... >>>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. >>> >>> >>> -- >>> Don Burn (MVP, Windows DKD) >>> Windows Filesystem and Driver Consulting >>> Website: http://www.windrvr.com >>> Blog: http://msmvps.com/blogs/WinDrvr >>> Remove StopSpam to reply >>> >>> >>> >>> "tanix" <tanix(a)mongo.net> wrote in message >>> news:hhdfs1$1it$8(a)news.eternal-september.org... >>>> In article <hhcoup$8am$1(a)atlantis.news.neostrada.pl>, >>>> =?ISO-8859-1?Q?Grzegorz_Wr=F3bel?= >>>> </dev/null(a)localhost.localdomain> wrote: >>>>>Tim Roberts wrote: >>>>>> Grzegorz Wr�bel </dev/null(a)localhost.localdomain> wrote: >>>>>> >>>>>>> Tim Roberts wrote: >>>>>>>> Get real. A software problem cannot cause your machine to lock up >>>>>>>> so hard >>>>>>>> that even mouse and keyboard stop. >>>>>>> Get rational. User mode app can lock up mouse and keyboard just by >>>>>>> starving system processes that manage mouse and keyboard input. On >>>>>>> the >>>>>>> single CPU/core machines it was very common to happen. On the multi >>>>>>> core >>>>>>> machines much less likely to happen "naturally", but still possible. >>>>>> >>>>>> No. A user mode app can certainly prevent other user mode apps from >>>>>> processing mouse and keyboard input, yes, but the mouse pointer keeps >>>>>> moving, and pressing the caps lock key still toggles the caps lock >>>>>> indicator. Stopping those requires the "assistance" of kernel code. >>>>> >>>>>No. The point is you can lock mouse and keyboard to the point that the >>>>>mouse cursor stops moving and no other application (including Windows >>>>>shell) can receive/process mouse and keyboard input. >>>> >>>> ONLY in not truly multitasking OS. >>>> >>>>>This is known issue, if you have never experienced it as a programmer, >>>>>you still can read about it in MSDN: >>>>>http://msdn.microsoft.com/en-us/library/ms685100(VS.85).aspx >>>> >>>> You can read all you want. >>>> >>>> Enough of this. >>>> >>>>>You can of course argue this is still "kernel code" that freezes the >>>>>box, but such argumentation doesn't have much sense since this code is >>>>>executed directly by user mode API calls. >>>>> >>>>> >>>>>This is the sample test code I once wrote to effectively freeze the >>>>>single CPU/core Windows box for 30 seconds (on post XP system you'll >>>>>need to run it elevated otherwise SetPriorityClass() will fail): >>>>> >>>>>//lockme.cpp >>>>> >>>>># include <windows.h> >>>>># include <math.h> >>>>> >>>>>int main() >>>>>{ >>>>> int i,j,k; >>>>> double a,b,c; >>>>> ULARGE_INTEGER start,current; >>>>> SYSTEMTIME st; >>>>> FILETIME ft; >>>>> >>>>> SetPriorityClass(GetCurrentProcess(),REALTIME_PRIORITY_CLASS); >>>>> >>>>> SetThreadPriority(GetCurrentThread(),THREAD_PRIORITY_TIME_CRITICAL); >>>>> >>>>> GetSystemTime(&st); >>>>> SystemTimeToFileTime(&st,&ft); >>>>> memcpy(&start,&ft,sizeof(ft)); >>>>> >>>>> for(;;){ //lets do some heavy computation; >>>>> c = 0.9; >>>>> a = sin(c); >>>>> b = cos(c); >>>>> c = log(pow(a,b)+c); >>>>> k = int(c)+5; >>>>> j = 4*k*k*k + 2*k*k + k + 1; >>>>> >>>>> GetSystemTime(&st); >>>>> SystemTimeToFileTime(&st,&ft); >>>>> memcpy(¤t,&ft,sizeof(ft)); >>>>> if(current.QuadPart-start.QuadPart>300000000) // release >>>>> the >>>>> lock >>>>>after 30 seconds >>>>> break; >>>>> } >>>>> >>>>> return 0; >>>>>} >>>>> >>>>> >>>>>The above code simply sets its base priority to 31 and then occupy CPU. >>>>> >>>>>Haven't tried it on multicore box, but presumably if you run it from >>>>>elevated console n times (when n is number of the CPU cores) you should >>>>>freeze the box too. Unless OS tries to reserve one core for itself >>>>>(unlikely). >>>>> >>>>> >>>> >>>> -- >>>> 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. >>>> >>>> >>>> __________ Information from ESET NOD32 Antivirus, version of virus >>>> signature database 4726 (20091229) __________ >>>> >>>> The message was checked by ESET NOD32 Antivirus. >>>> >>>> http://www.eset.com >>>> >>>> >>>> >>> >>> >>> >>> __________ Information from ESET NOD32 Antivirus, version of virus >>> signature database 4726 (20091229) __________ >>> >>> The message was checked by ESET NOD32 Antivirus. >>> >>> http://www.eset.com >>> >>> >>> >>> >> >> > > -- 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 29 Dec 2009 23:55 In article <uGiwMvOiKHA.2188(a)TK2MSFTNGP04.phx.gbl>, "Boba" <Boba(a)somewhere.net> wrote: >"tanix" <tanix(a)mongo.net> wrote in message >news:hhc19f$r7h$3(a)news.eternal-september.org... >> In article <O9u0FFDiKHA.5380(a)TK2MSFTNGP06.phx.gbl>, "Boba" >> <Boba(a)somewhere.net> wrote: >>... >>>>But you said "Windows is not a proper multitasking OS" >> >> Is it? >> >>>I did not say that (though I do partially agree with that). >>>Boba TC. > >not to the depth of my knoweledge. (at least _not_yet_, for sure.) >there are situations when windows runs stable for awhile emulating >multitasking among internal tasks spawned by itself. boba. One more time: Window is NOT, and probably never will be, a truly multitasking OS. Simple as that. And ALL the arguments about "screwed up" drivers will never make it all work. Just because some of you "never" seen a crash of OS, which I really doubt, becaus I have to reboot the box at least once in a couple of days, does not mean that OS is running like a tank. Just leave it running for a month and let it automatically do some more or less complex things, if you EVER see anything on the screen after that. Then close all your programs. What is going to happen to your memory? I do not recall ever being able to run win for more than a week. After a couple of days, ALL sorts of "miracles" start happening. Things begin to freeze or behave in weird ways, sluggisthness may appear in things that work perfectly for the most part, and ALL sort os magic, like some things totally screwing up the display. Just a SINGLE fact that windows periodically redraws your ENTIRE desktop, especially when you click on some things in the explored, means what? And this has been happening to windows since the day one. Especially on the machines that are not the fastest in the world, you may end up loosing control of what you do because when you click on something, or change which instance of explorer you are on, or click on a + sign in the folder view, the WHOLE desktop redraws, which takes SECONDS in some cases. AND that kind of thing happens ALL THE TIME. To the point that you start making mistakes becuase what you think you have done is not what actually happened in terms of win interpreting. So, you may delete files, move the entire directories around, or ALL sorts of "magic". And what does THAT tell you? -- 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: Boba on 30 Dec 2009 05:40 "tanix" <tanix(a)mongo.net> wrote in message news:hhemg5$k12$9(a)news.eternal-september.org... > ... > So, you may delete files, move the entire directories around, > or ALL sorts of "magic". been there, seen that... had data lost ;( > And what does THAT tell you? THAT should also tell you not to use winblows for that type of business.
From: Don Burn on 30 Dec 2009 09:50
"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. You do realize that the arguement over bottom versus top posting is older than Usenet? It has always depended on the user's tastes, the software doing the reading and the performance of the connection. I can remember Usenet wars of 25 years ago where people were vilified for bottom posting. > 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. > 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. -- Don Burn (MVP, Windows DKD) Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr Remove StopSpam to reply __________ Information from ESET NOD32 Antivirus, version of virus signature database 4729 (20091230) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com |