One busy thread locks machine?

  • Thread starter Thread starter Armin Zingler
  • Start date Start date
A

Armin Zingler

Hi altogether,

this is really strange: How can one busy thread lock the whole machine?
Code: (just for testing!)

Shared Sub Main()
'Process.GetCurrentProcess.PriorityClass = ProcessPriorityClass.RealTime
'Threading.Thread.CurrentThread.Priority = Threading.ThreadPriority.Highest
WaitHeavy(10000)
End Sub

'I know that there is Thread.Sleep() but that's not the point.
Private Shared Sub WaitHeavy(ByVal Milliseconds As Integer)
Dim watch = Stopwatch.StartNew

Do Until watch.ElapsedMilliseconds >= Milliseconds
Loop
End Sub

It does what expected: It keeps one of the three available cores
busy (i.e. 33% total CPU usage) and quits after 10 seconds.

BUT: After uncommenting the two lines, the machine starts
reacting slower and is finally gets locked completely!
If I press Ctrl+Alt+Del, not even the mouse pointer can
be moved anymore. NumLock/CapsLock LEDs can't be switched.
(Maybe you have to change the interval to 30000 to reproduce it.)

On a triple-core??? How comes? I've never seen this before.
After the app quits, everything's back to normal.

(Win7/64 on Athlon II X3, 4 GB RAM)
 
Am 17.03.2011 01:50, schrieb Armin Zingler:
On a triple-core??? How comes? I've never seen this before.
After the app quits, everything's back to normal.

(Win7/64 on Athlon II X3, 4 GB RAM)
Click to expand...

Of course, nothing else is running in the background.

But if I start e.g. playing a video in the background,
it stopps, and catches up after my app quits - with
persons moving much too quickly.

If I start another thread in the background in order
to collect CPU usage percantage every second, it
collects nothing because it's also blocked. If I set
this thread's priority to Highest, too, if does collect
data. And what does the data say? 33%! So, as there
is 66% CPU capacity available, how can my (user mode)
application cause an (obvious) kernel mode lock on
whatever?
 
Armin Zingler explained :
Hi altogether,

this is really strange: How can one busy thread lock the whole machine?
Code: (just for testing!)

Shared Sub Main()
'Process.GetCurrentProcess.PriorityClass =
ProcessPriorityClass.RealTime
Click to expand...

this is probably your culprit - a thread in a process with
ProcessPriorityClass.RealTime can preempt even os threads....

from the docs:

RealTime

Specifies that the process has the highest possible priority.

Caution:
The threads of a process with RealTime priority preempt the threads of
all other processes, including operating system processes performing
important tasks. Thus, a RealTime priority process that executes for
more than a very brief interval can cause disk caches not to flush or
cause the mouse to be unresponsive.
 
Am 17.03.2011 05:07, schrieb Tom Shelton:
Armin Zingler explained :

this is probably your culprit - a thread in a process with
ProcessPriorityClass.RealTime can preempt even os threads....

from the docs:

RealTime

Specifies that the process has the highest possible priority.

Caution:
The threads of a process with RealTime priority preempt the threads of
all other processes, including operating system processes performing
important tasks. Thus, a RealTime priority process that executes for
more than a very brief interval can cause disk caches not to flush or
cause the mouse to be unresponsive.
Click to expand...

Hi Tom,

thanks for your reply. Also for your answer to my "Declare AUTO function"
question. I did other things in the meantime and forgot to answer.
Sorry for that!

Yes, it can, if there's no other CPU core. That's why I didn't do it
on my single-core some years ago. It was too dangerous. But after that,
since I had a dual-core, I've done this many many times (for my own
testing purposes only) and it /never/ behaved like that anymore. That's
why I'm so surprised, now, with a triple-core. It must be the
constellation of hardware and drivers on my new machine with a new OS
that causes this. I have no other reasonable explanation.

Really, this doesn't make sense. It's contrary to my basic understanding
of how the Windows scheduler works. I must have been under a
misapprehension all the years. I still think, as long as there's 2/3 free
CPU capacity, this must not happen in a (user mode) application.
 
Armin Zingler expressed precisely :
Am 17.03.2011 05:07, schrieb Tom Shelton:

Hi Tom,

thanks for your reply. Also for your answer to my "Declare AUTO function"
question. I did other things in the meantime and forgot to answer.
Sorry for that!

Yes, it can, if there's no other CPU core. That's why I didn't do it
on my single-core some years ago. It was too dangerous. But after that,
since I had a dual-core, I've done this many many times (for my own
testing purposes only) and it /never/ behaved like that anymore. That's
why I'm so surprised, now, with a triple-core. It must be the
constellation of hardware and drivers on my new machine with a new OS
that causes this. I have no other reasonable explanation.

Really, this doesn't make sense. It's contrary to my basic understanding
of how the Windows scheduler works. I must have been under a
misapprehension all the years. I still think, as long as there's 2/3 free
CPU capacity, this must not happen in a (user mode) application.
Click to expand...

When a process has realtime priority, it gets all of the os's attention
- so, threads from other processes, including the OS take a back seat.
So, it really doesn't matter how many cores you have, lower priority
processes aren't going to get any cpu time....
 
Am 17.03.2011 16:47, schrieb Tom Shelton:
When a process has realtime priority, it gets all of the os's attention
- so, threads from other processes, including the OS take a back seat.
So, it really doesn't matter how many cores you have, lower priority
processes aren't going to get any cpu time....
Click to expand...

Never been so with XP-32. Must be new in Vista/7.
 
Back
Top