Re: Problem with XP scheduler?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

In article <#cJ1l6LiKHA.1460@xxxxxxxxxxxxxxxxxxxx>, "Alexander Grigoriev" <alegr@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:emgj$XLiKHA.1824@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx> wrote in message
news:hhdfs1$1it$8@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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
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(&current,&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.

.

Relevant Pages

  • Re: Problem with XP scheduler?
    ... A software problem cannot cause your machine to lock up so hard ... User mode app can lock up mouse and keyboard just by ... machines much less likely to happen "naturally", ... A user mode app can certainly prevent other user mode apps from ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Problem with XP scheduler?
    ... User mode app can lock up mouse and keyboard just by ... starving system processes that manage mouse and keyboard input. ... A user mode app can certainly prevent other user mode apps from ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Problem with XP scheduler?
    ... A software problem cannot cause your machine to lock up so hard ... User mode app can lock up mouse and keyboard just by ... machines much less likely to happen "naturally", ... A user mode app can certainly prevent other user mode apps from ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Problem with XP scheduler?
    ... I think you'll agree that Windows scheduler could do better job for taming ... User mode app can lock up mouse and keyboard just by ... starving system processes that manage mouse and keyboard input. ... A user mode app can certainly prevent other user mode apps from ...
    (microsoft.public.win32.programmer.kernel)
  • Re: keyboard lockout
    ... Unplug keyboard, take it with you. ... Windows cannot lock out the key board to my knowledge. ... Do a search for 'Keyboard lockout' or 'lock keyboard.' ...
    (microsoft.public.security)