[ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

[Ove Kaaven]

søn, 29.08.2004 kl. 04.13 skrev Michael Chang:
> > I argued with myself about the logic in this for ages. The best I could 
> > come up with is - I don't know :| I'd need to know about windows 
> > scheduling (which I don't)
> 
> Obviously, if Win apps have been written to expect this, there's
> documentation somewhere... if someone has free time, maybe look for it?

A book I have described how it works...

The Windows scheduler is in its most basic form remarkably similar to
the scheduling policy known in Linux as SCHED_RR, with a few
"enhancements". For example, the thread owning the foreground window
gets a priority boost relative to other threads in the system. There's
also some stuff in there to help deal with the priority-inversion
problem known to real-time programmers, I think. (When a low priority
thread can keep blocking the execution of a high priority thread by
holding a lock the high priority thread needs, with the result that
medium priority threads get to run but the high priority thread does
not, it's called priority inversion, if I understand right.)

Also note that Windows allows a Win32 process to boost its own priority
all the way to what they call "real time". Only root can do this under
Linux. I'm not sure if you need administrator privileges to do this
under Windows (probably not), but since every Windows user runs as
administrator anyway, it's probably not unlikely that many applications
expect this ability anyway.

Internally, Windows assigns each thread a priority, determined by
process priority class, thread priority class (all programmatically
set), and some other factors such as whether it's running in the
foreground (owns the foreground window) or not. Threads with the same
scheduling priority are scheduled round-robin. Threads with higher
priority preempt anything with lower priority, so that lower priority
threads will not get to run as long as a higher priority thread is
runnable. It is of course recommended and assumed that applications use
high priority only for threads that won't use much CPU, since if they
do, execution of that thread will block all threads with lower priority
than itself.

The book described no kind of dynamic scheduling based on how much CPU
time a thread is spending, only the aforementioned "is in foreground"
thing. Does imply that a Win32 app running an infinite loop could run
fine in the background, but would hang the system if brought to the
foreground, I think (assuming Windows doesn't see that it has hung,
which it probably checks by seeing if it responds to messages).

> > and how wine treats that scheduling (which I also don't).

I don't see how that's relevant. Wine doesn't schedule threads, the
Linux kernel does.