On Sun, Aug 29, 2004 at 09:51:30AM +0200, 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".
As I recall, most apps fall under two catagories (basically): a) those who don't bother with priority (they use the default one, mostly toward lesser end users and general audiences) and b) those who allow the user to change this via a menu or command line option (advanced apps only or advanced feature only).
Of the latter, there seem to be mostly two types: a) those who allow general priority change, but only to a minor extent (i.e. High/Normal/Low, as seen in the Windows' Version of POV-Ray) and b) those who allow all priority choices (such as Windows' Gameboy Emulators that I've seen, Visual Boy Advance comes to mind).
Only root can do this under Linux.
Maybe I sound naive, but would it be possible to get the highest priority supported by the user (root or otherwise) without going to root; getting as close to real-time as possible? It would be a performance hit as opposed to actually using real-time, but otherwise, we'd be okay, I guess...
I'm not sure if you need administrator privileges to do this under Windows (probably not),
On 3.1 and 9x series, where there was no user administration, this was 100% true, since a) only one user at a time, b) file system didn't allow privilages (FAT), and c) the "users" in the default windows just stored settings, (different user registries and desktops and doc folders and such), unless in netware or a such setting, but those didn't control CPU usage, only resource usage on the network.
but since every Windows user runs as administrator anyway, it's probably not unlikely that many applications
Except in recent Windows versions, such as XP and it's NTFS 5 or whatever filesystem which now supports advanced privilages and user administration (such as a super user, the only guy who can install apps and run certain apps and access certain folders). In XP, there's actually an "administrator" and "users"!
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.
He didn't say wine scheduled the threads. He said how wine *treats* that scheduling. Which makes sense. You have to figure out how to sync all the threads in an app, and then compare how to sync the different apps to emulate the scheduling -- if you don't, then you end up with desynced threads, garbling video, audio, keyboard handling, processing, etctera. It's sort of like how wine deals with the linux scheduling and windows scheduling, by trying to bridge the gap between the two.
Remember, I'm just a Windows/Linux user, and this is all sepculation.
--Michael Chang