Tue Nov 20 00:56:47 2001
What Gives?
Besides, we need some OS tagnutry in here. So..............
\
EXPLAIN!
Tue Nov 20 01:24:24 2001
Threads can have different priorities. NT has 32 i believe, with Idle at one end and RealTime at the other. (I can't remember if realtime is 0 or 32... it's not readily apparent since it's like I confessed, I've never looked it up on NT )
Threads also have states: sleep, wait, running, ready to run, things like that. (some OS's may have a blocking state, but I consider wait to be the same thing)
Idle prio threads only run when every other thread that the kernel is scheduling is either in a sleep state, or a wait state.
There is also a specific "Idle Thread" that is built into the OS, which almost always calls HLT to cool the processor. (ever heard of CPU Cool or something like that? It had a device driver that ran a thread at the lowest prio and only called HLT. supposedly it lowered CPU temps 5-10 degrees.) It runs at the lowest prio, some OS's may not even let you have more than 1 thread at that lowest level, only the next one up.
Also, lets say a high prio thread is trying to get ahold of a semaphore. This sem is being held by a low prio thread. In order to get the higher prio thread running sooner, some OS's will do a prio inversion. Now, I'm not certain if that moves them as close to realtime as they are near idle (which would be worthless for prio 16 threads) or if it just adds a few to the prio level. But, the reasoning is that the newly higer prio thread will be able to release it's sem, at which case it will soon be pre-empted, at which time it's prio is lowered to its original level.
I think that discussion came up because of the possibilty (and I'm in "talk out of my ass mode" now since I have done 0 research into this) that OS X has 2 different kind of "idle" threads. GUI idle, and CLI idle. GUI idles being much higher on the totem pole than CLI idles would explain kurt-o's experiences. But, since I don't know this is the case, and don't really feel like looking further into it, I'm gonna let it slide.
I hope most of this made some kind of sense. I really really love this stuff. :) I need more time to read my OS design books :( (and damnit I want to start werkin on one someday! I'll fight with Bochs if I have to ;) )
Tue Nov 20 03:53:28 2001
Granted I do the same thing. But i'm special so all is forgiven.
Tue Nov 20 04:00:46 2001
that was actually a decent thread. Nice to see that not to many uneducated posters are in there jumping in and posting what they think they understand from what they have read from people who them selves have read some articles someplace else and understand just some of it.
I don't mind people making errors in argument, as such is the way to establishing fact and eliminating falacy.
It's mindless idiocy that bothers me.
Tue Nov 20 12:57:29 2001
Tue Nov 20 19:41:12 2001
I think that discussion came up because of the possibilty (and I'm in "talk out of my ass mode" now since I have done 0 research into this) that OS X has 2 different kind of "idle" threads. GUI idle, and CLI idle. GUI idles being much higher on the totem pole than CLI idles would explain kurt-o's experiences. But, since I don't know this is the case, and don't really feel like looking further into it, I'm gonna let it slide.
Threads can have different priorities. NT has 32 i believe, with Idle at one end and RealTime at the other. (I can't remember if realtime is 0 or 32... it's not readily apparent since it's like I confessed, I've never looked it up on NT )
Tasks can't run at priority zero (only the idle pseudo-thread can be, which runs a HLT, which stops the processor <strong>dead</strong>, to all but hardware interrupts), and only drivers can run at priority 32. This leaves the rest as normal priorities. The software priorities are a bit of an illusion -- they're all equivalent, it's just the OS favours some over others.
There are a bunch of hardware priorities (all above 32), but only a few are normally used. These work a bit differently from regular thread priorities, because they have features such as masking off interrupts. The very highest priority thread can't be interrupted by hardware interrupts (and, if it turns off NMIs, can't be interrupted by them, either).
Tue Nov 20 20:23:07 2001
It'd be ludicrous if true. Giving a boost to the foreground thread [that is, the one receiving input] is all well and good (it leads to a nicer UX), but there's no point in making GUI apps plain ol' <em>more important</em> than CLI ones.
Thanks for the misc info.