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

[Con Kolivas]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20040829/4d2b06ba/signature.pgp