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

[michael at cherryblossom.homelinux.com]

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