Re: Problem with XP scheduler?
- From: tanix@xxxxxxxxx (tanix)
- Date: Tue, 29 Dec 2009 17:56:18 GMT
In article <hhcoup$8am$1@xxxxxxxxxxxxxxxxxxxxxxxxxx>, =?ISO-8859-1?Q?Grzegorz_Wr=F3bel?=
</dev/null@xxxxxxxxxxxxxxxxxxxxx> wrote:
Tim Roberts wrote:
Grzegorz Wróbel </dev/null@xxxxxxxxxxxxxxxxxxxxx> wrote:
Tim Roberts wrote:
Get real. A software problem cannot cause your machine to lock up so hardGet rational. User mode app can lock up mouse and keyboard just by
that even mouse and keyboard stop.
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.
.
- Follow-Ups:
- Re: Problem with XP scheduler?
- From: Don Burn
- Re: Problem with XP scheduler?
- References:
- Problem with XP scheduler?
- From: tanix
- Re: Problem with XP scheduler?
- From: Tim Roberts
- Re: Problem with XP scheduler?
- From: Grzegorz Wróbel
- Re: Problem with XP scheduler?
- From: Tim Roberts
- Re: Problem with XP scheduler?
- From: Grzegorz Wróbel
- Problem with XP scheduler?
- Prev by Date: Re: Problem with XP scheduler?
- Next by Date: Re: Problem with XP scheduler?
- Previous by thread: Re: Problem with XP scheduler?
- Next by thread: Re: Problem with XP scheduler?
- Index(es):
Relevant Pages
|