Clarification of Pre-Emptive Execution

[Gary Beene]

From HELP I read the comment:

When Code is running in a tight Loop, it is quite possible to use up 100% of the available 'CPU time

Isn't that ok, as long as the thread is using up the CPU only in its allocated time-slice?

I thought Windows was pre-emptive - that it forced threads to give up CPU usage once their time-slice was over. So how is it that an application can seem to hog CPU time and slow down other threads/processes - unless Windows is giving it an inordinate number of time-slices?

The Help statement also made me wonder what is a tight loop?

For i = 1 to 10              '? tight
Next i
For i = 1 to 10              '? tight
    j = 2 * i
Next i
For i = 1 to 10              '? tight
   Sleep 1000
Next i

Is there such a thing as a not-tight loop?

We've all seen apps hog CPU time. I just haven't thought about it enough to have asked the questions above.

Can someone clarify the big picture for me?

[John Petty]

The Help statement also made me wonder what is a tight loop?
Is there such a thing as a not-tight loop?

Probably easier to answer the second question first. A non-tight loop is one that contains a slow blocking statement to the O/S like a disk action or TCP/IP action (just examples, not all disk or TCP/IP statements are blocking) so the thread or application gives up its time slot at that point and does not receive another one until that action is complete. The answer to your first question is obviously the reverse of that only manipulating for long periods data that is already in memory.
Is there anything wrong with writing a program that causes 100% CPU usage, the answer is no and yes. To understand, use Task Manager and on the Processes tab sort by maximum CPU usage, most of the time the System Idle Process has most CPU time. This means any app running can get as many time slices as it needs without waiting so no app appears to slow down. I have a number of apps where the code is carefully tailored to achieve a 100% CPU usage i.e. 0% System Idle Time (I don't pay lazy workers ).
So what are the effects? There are two main ones, the other apps running will most likely contain blocking statements so will give up there time slice on that statement and so not be getting an equal share of the time slices and so run a little slower as the "tight loop", getting its time slice in rotation, uses all its time slot. Not a big problem, imagine how few time slices I am using to type this response. The biggest problem is usually in your own app which can't respond to any windows messages like repaint so you get the dreaded white screen. The answer to that is is to break your app into two, thus a thread, each now gets its own time slice so that problem dissapears. PB makes it easy, VB on the other hand strictly used a single threaded apartment model which required kludges to try and get around it (amazingly the bad approach still exists in some important Microsoft applications like ScanPST). Actually I have no problem say browsing the net and running an app at the same time with 100% CPU usage.