Problem with XP scheduler?
in [Win32 Kernel]
|
From: Alexander Grigoriev on 29 Dec 2009 13:13 Only mouse hardware is handled by kernel. Mouse drawing is handled by GDI, which partially runs in user mode. "tanix" <tanix(a)mongo.net> wrote in message news:hhdg1m$1it$9(a)news.eternal-september.org... > In article <#EdyJPJiKHA.6096(a)TK2MSFTNGP02.phx.gbl>, "Paul Baker [MVP, > Windows Desktop Experience]" <paulrichardbaker(a)community.nospam> wrote: >>There was a day where Windows would lock up in this manner, not to mention >>crash in many different spectacular ways, and commonly. I think it became >>a >>kneejerk reaction to any frustrating Windows crash for someone to say >>"Windows crashes like that all the time... you should use *X instead". >>While >>this may have been justifiable at that time (though simplistic unecessary >>bashing IMO), those days are long gone. > > :--} > > Is this some kind of a joke? > > What do you think I am seeing here? > Some woodoo magic? > > And I tell you, I am seeing a KERNEL screwing up to the point > beyond belief, which is represented by loosing control of the > highest priority device, a mouse, that is ran by the kernel, > and nothing less. > > I really do not understand the purpose of all this gibberish. > >>I too do not recall a single instance of a system wide crash for several >>years, and before that several more years. >> >>Paul >> >>"Liviu" <lab2k1(a)gmail.c0m> wrote in message >>news:%23m1aC6FiKHA.1540(a)TK2MSFTNGP06.phx.gbl... >>> "tanix" <tanix(a)mongo.net> wrote... >>>> In article <ObYOMm$hKHA.5020(a)TK2MSFTNGP02.phx.gbl>, "Liviu" >>>> <lab2k1(a)gmail.c0m> wrote: >>>>>"Tim Roberts" <timr(a)probo.com> wrote... >>>>> >>>>>> The likely issues are [...] (2) graphics driver problem, >>>> >>>> I doubt, but who knows. Just the fact that nothing else causes >>>> this kind of lockup does not mean it is certainly not a graphics >>>> driver, although I have my doubts. >>> >>> As I said, one step to check that theory would be to run the stock >>> SVGA driver and try to duplicate the problem. >>> >>> In addition to Tim's shortlist of suspects, I'd also suggest >>> (4) overclocking and (5) overloading the power supply. >>> >>>> To me, these kinds of lockups are so common that to call windows >>>> a fully multitasking OS is not only a joke. It is pathetic. >>> >>> To me, those kind of lockups are virtually absent. Can't honestly >>> remember the last time I had to use the hard reset button. YMMV and >>> apparently does. Yet, that doesn't automatically make it OS's fault. >>> >>> 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. >
From: Don Burn on 29 Dec 2009 13:37 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
From: Alexander Grigoriev on 29 Dec 2009 14:39 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 > > > >
From: Don Burn on 29 Dec 2009 15:02 No arguement that there are problems with the Windows scheduler, but like everything else in an OS once you release it someone will start depending on that behavior and be very annoyed when you change it. I have worked with companies using Windows in embedded environments where the behavior you complain about is expected so that a critical task can be completed within certain time constraints. My real complaint with this whole discussion is that multitasking means different things to different people. If you are an old timer like me, there were major screams 30 years ago when Unix claimed to be multitasking. At that time most companies described what we now consider as multitasking as multiprocessing and that tasks were what we currently call threads. And 30 years ago, Unix did not support threads. -- 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 "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 >> >> >> >> > > > > __________ 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
From: Paul Baker [MVP, Windows Desktop Experience] on 29 Dec 2009 17:00
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 >> >> >> >> > > |