Re: Tweaking windows XP question

Am Sat, 25 Feb 2006 19:24:59 GMT schrieb nappy:

"leutholl" <leutholl@xxxxxxxxxxx> wrote in message
news:28ynikrxmdsv$.l804d8pin6vq.dlg@xxxxxxxxxxxxx

I have tried it as all products I am currently developing are large
multithreaded apps. There are very good resources to better understand
this
on the web. I have found Jeffery Richter's book "Applications for
Windows" a
great help in understanding this.

Oh yes I agree while this is true for not a TIME_CRITICAL application.
But if you write realtime apps in WinXP and you don't give sleeps(),
nothing else will run! You have the whole CPU just for you! Otherwise this
priority wouldn't named REATLIME.

No this is also wrong. In fact, using Sleep() is not really encouraged by
anyone. Good code design is.
The thread scheduler will schedule your thread whether or not any other
threads actually invoke Sleep().
Some Windows programmers decry the use of Sleep(). Purists that they are.




I wrote serveral realtime apps in WinXP and to give back CPU sliced to the
scheduler with sleeps you will end up the UI hangs, no mouse, no
everything
except your thread. That's the challenge for every implementer to know
where and how long to sleep.

If you put a thread to sleep other threads are not affected. Like Mouse,
etc. If your thread is deadlocked or in a race condition or failing in some
other way then you could end up with everything locked. But that would be a
result of poor program design rather than normal thread scheduler operation.

As you know, you have to set the priority for the process AND the thread
within! Otherwise, this is not true!

Not sure what you are saying there. Anymore I try not to bump thread
priorities unless it is absolutely neccesary and unsolvable any other way.


Do you agree with this?

Richter's book is very good. While I do not claim to know everything about
multithreaded apps it did enlighten me about the scheduler and how it
manipulates thread priorities, etc...



Lukas

OK to make my conlcusion:

The scheduler under WinXP works like this:

Every thread has a thread priority assigned to it. Threads created within
the common language runtime are initially assigned the priority of
ThreadPriority.Normal. Threads created outside the runtime retain the
priority they had before they entered the managed environment. You can get
or set the priority of any thread with the Thread.Priority property.

Threads are scheduled for execution based on their priority. Even though
threads are executing within the runtime, all threads are assigned
processor time slices by the operating system. The details of the
scheduling algorithm used to determine the order in which threads are
executed varies with each operating system. Under some operating systems,
the thread with the highest priority (of those threads that can be
executed) is always scheduled to run first. If multiple threads with the
same priority are all available, the scheduler cycles through the threads
at that priority, giving each thread a fixed time slice in which to
execute. As long as a thread with a higher priority is available to run,
lower priority threads do not get to execute. When there are no more
runnable threads at a given priority, the scheduler moves to the next lower
priority and schedules the threads at that priority for execution. If a
higher priority thread becomes runnable, the lower priority thread is
preempted and the higher priority thread is allowed to execute once again.
On top of all that, the operating system can also adjust thread priorities
dynamically as an application's user interface is moved between foreground
and background. Other operating systems might choose to use a different
scheduling algorithm.

There are 32 thread priorities including the priority class of the process.
Number 31 - the highest - is TIME_CRITICAL inside a REAL_TIME class. If you
have apps with lower priorty they will never be executed by the scheduler.
If you have one with the same priority, the scheduler decides, when to
preempt and when not!
System level things like input, cursor, chache flushing, file sys, drivers
etc... have a priority of NORMAL inside the REAL_TIME class.
Write an application with priority 31 and if you take all the time the
scheduler gives to you (and he will) you have all CPU power you can have
for an application or kernel mode if you do.

I agree that WinXP is not a realtime os per se, but for audio with latency
down to 1ms winXP is fast enough to guarantee realtime performance for
this. Take a look at WINSEM, 100us is possible in usermode.
WinXP is not so bad as lot of people think!

You will find more information directly at MS in the MSDN Library.

Lukas
.

Relevant Pages

  • Re: RFC for a new Scheduling policy/class in the Linux-kernel
    ... B is holding a lock. ... A grants its priority B until B releases the lock. ... We want to charge B's critical section to B, ... scheduler computes how much time A has used recently, ...
    (Linux-Kernel)
  • [RFC][PATCH] O(1) Entitlement Based Scheduler
    ... This patch is a modification of the Oscheduler that introduces ... _entitlement_ to CPU resources that is determined by the number of _shares_ ... This patch provides both soft and hard CPU usage rate caps per ... one getting the most can be given a better priority, ...
    (Linux-Kernel)
  • Re: RFC for a new Scheduling policy/class in the Linux-kernel
    ... A grants its priority B until B releases the lock. ... We want to charge B's critical section to B, ... spent while holding locks. ... scheduler computes how much time A has used recently, ...
    (Linux-Kernel)
  • Re: Renice X for cpu schedulers
    ... (That's all that any of these dynamic priority heuristics ... really seem to do -- weight the scheduler towards switching to ... the design _intent_; but I think it's fairly accurate in terms of the ... non-threaded design of the X server makes it ...
    (Linux-Kernel)
  • [patch] 2.6.21-rc4 nicksched v32
    ... Considering the recent attention on CPU schedulers, ... but it is yet another scheduler. ... struct pipe_inode_info; ... 'User priority' is the nice value converted to something we ...
    (Linux-Kernel)