Sleep(0) and THREAD_PRIORITY_HIGHEST
Javier Martínez
If I call Sleep API with a zero value causes the thread to relinquish the
remainder of its time slice to any other thread of equal priority that is
ready to run. If there are no other threads of equal priority ready to run,
the function returns immediately, and the thread continues execution.
But.... What happends if the thread is THREAD_PRIORITY_HIGHEST? The thread
continues its execution or the slice is to other theread with a lower
priority?
Thanks in advance.
Javier
Jochen Kalmbach
You already explained it...
Your thread will run.... until an other thread with higher or same priority
wants to run...
--
Greetings
Jochen
Do you need a memory-leak finder ?
http://www.codeproject.com/tools/leakfinder.asp
Javier Martínez
Because there isn't another thread with higher or same priority.
"Jochen Kalmbach" <nospam-Joch...@holzma.de> escribió en el mensaje
news:Xns943670C84EAB7J...@127.0.0.1...
Jochen Kalmbach
> Then.. If my thread has THREAD_PRIORITY_HIGHEST the Sleep(0) is NOT
> useful? Because there isn't another thread with higher or same
> priority.
I do not know if there is ahigher prio thread...
But if you do
while(1)
{
// do some other stuff
Sleep(0);
}
you windows does not respond anymore (on a single CPU system); if also
REALTIME_PRIORITY_CLASS is set.
Hector Santos
"Javier Martínez" <ja...@tid.es> wrote in message
news:eMIXCOP...@tk2msftngp13.phx.gbl...
> Then.. If my thread has THREAD_PRIORITY_HIGHEST the Sleep(0) is NOT
useful?
> Because there isn't another thread with higher or same priority.
For the most part, you are correct. But it all depends on how you are using
Sleep(0). If used incorrectly, you could bog down your system. It will be
very inefficient. If you are just using here it poke the scheduler, thats
fine, but in a tight loop, you have to watch for this.
Think about what you are telling Windows to do when you use Sleep(0) and
also consider that eveyone must share the same CPU, bus, etc.
In general, under Windows, which is not a true RTOS (real time operating
system), using Sleep(0) is not a true yield as in a RTOS and if you use it a
tight loop, calling it many times, will cause high context switching.
So if there aren't other threads to be running at the SAME level, its going
to be switching back and forth so much, your CPU drag will be very high.
Now if you increase the priority, you make it worst. While the scheduler
will time slice the equal priority thread better now, the high priority
thread with using Sleep(0) in a tight loop is going to be interrupting now
only its equal priority threads but the lower priority threads as well. So
there is will alot of context switching.
It is better to use something like Sleep(1) or so which will give it some
residence time (at least 10-13 msecs depending on the OS and hardware), this
allowing the Window scheduler to time slice better, but more importantly the
context switching is reduced.
Look at it this way:
The more context switching you have, the more the other threads will be
preempted making those threads less efficient as well. So basically what
you are telling windows to do is to reduce the residence time a thread will
have because you are telling window to stop it, and go back to the sleep(0)
thread immediately. It is doing this so many times, that your system is
basically running very inefficient.
In a nut shell, the basic definition of a RTOS is that the residence time
for each thread is guaranteed. Equal round robin time slicing. Windows CE
is suppose to offer RTOS functionality. Real time programmers demand this
functionality. So in a RTOS, a Sleep(0) is a true yield and it is suppose
to give every thread time to do some work before it comes back. That's not
the case with standard Windows. If you use Sleep(0) incorrectly, your system
efficiency degrades.
In short, don't do this:
while(1) {
// ....
// op code that takes less than 1 quantum and no kernel wait
objects
// .....
Sleep(0)
}
Just change it by giving the sleep some time, like Sleep(1) or Sleep(10),
etc.
Now, if all this is about getting the thread to do a lot of work very fast,
well, go ahead and increase the priority, but you must think about not being
a HOG and allow windows to give other threads to do some work. Everyone on
must share that CPU. Its that simple. Consider even possibly using a kernel
wait object with 0 time. Windows will do better time slicing when using
kernel wait objects. In fact, it gives you a way to break out of a loop by
signaling the wait object if indeed you need this type of logic.
Hope this provides some insight.
--
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com
Arkady Frenkel
Arkady
"Jochen Kalmbach" <nospam-Joch...@holzma.de> wrote in message
news:Xns943677622AB4DJ...@127.0.0.1...
Norman Black
ready to run to be switched to even if the thread has a lower priority
than the current thread.
--
Norman Black
Stony Brook Software
"Javier Martínez" <ja...@tid.es> wrote in message
news:eihYqGPr...@tk2msftngp13.phx.gbl...
Jochen Kalmbach
> Even with highest priority , threads of OS work without any problems.
> Arkady
Have you tried it !?
The following program locks up your computer (on single processor systems):
Only interrups are served...
int main()
{
char cTest;
SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);
while(1) {
cTest++;
Arkady Frenkel
priority to REALTIME_PRIORITY_CLASS the results were even worse that
without it ( about 1- 1.2 ms more that usual ( with default FIFO ) 5.5 - 5.6
ms ) .
Arkady
"Jochen Kalmbach" <nospam-Joch...@holzma.de> wrote in message
news:Xns94374BAE067CFJ...@127.0.0.1...
Norman Black
> Have you tried it !?
Yes I use the API. It only exists on NT based systems and then only NT
4.0 and later. The API only affects threads in the current processor
queue. I have never setup a test case to test its behavior. When the API
was added I changed my threading encapsulation to use SwitchToThread
when available instead of Sleep(0). That is the extent of my testing. I
took it for granted that the API did as it is supposed to do, otherwise
why would MS create a new API when Sleep(0) could be used unless the new
API does something slightly different.
Alexander Grigoriev
priority levels, highest is supposed to be realtime.
"Arkady Frenkel" <arkadyf@hotmailxdotxcom> wrote in message
news:OQsvQ9ar...@TK2MSFTNGP11.phx.gbl...
Jochen Kalmbach
>>>SwitchToThread
>> Have you tried it !?
My question has nothing to do with the "SwitchToThread" function!!!
My question was about "locking up the system" with "Sleep(0)" !!!