Ove Kaaven wrote:
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).
Thanks. That's useful to know. To be honest, knowing how linux manipulates priorities dynamically and that more of the OS is threaded at different layers from windows, it is a miracle than any of the high performance gaming might run smoothly.
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.
Audio runs as a separate thread outside of wine potentially through who knows how many layers as a combination of both process and kernel context so that's already complicating the issue by having a separate thread. X does the same again. So what the win32 game is doing under wine when it asks for audio or graphics to be done will be handled completely differently to windows. How blocking is done between the graphics and audio calls, when you have a highly cpu bound task (the game) as well is definitely complex and not just the kernel that is responsible here. Add to that the fact that wine itself runs a few threads and as I said before, it's a miracle it runs smoothly at all.
Cheers, Con