cas
Learning Storage Performance
I hope you will excuse the new thread, but smp and threading issues have little to do with the way I look. ( Ok, maybe a little. Think geek. )
NT thread scheduling in a uniprocessor system is actually pretty simple. The highest priority thread, which is ready to run, gets the processor. If multiple threads of the same priority are ready to run, the processor is shared among them in a round robin fashion. Each thread will run for a period of time, called a quantum. Once the quantum has expired, the next same priority thread is scheduled to run.
In an attempt to increase throughput, improve the responsiveness of interactive programs, and ameliorate the effects of poorly coded programs, NT will occasionally boost the priority of a thread.
Thread scheduling in a multiprocessor system is a bit more complicated, due largely to attempts to limit FSB and memory bus contention. Generally speaking, the highest priority n threads, will run on an n-way machine. Lower priority threads may run in some cases due to processor affinity masks, which limit a thread to specific cpus. Even in the absence of application defined masks, the OS will attempt to schedule a thread on its ideal processor, or at least the last one on which it ran, because there is a good chance its working set in still in the processor’s cache.
If I were describing a traditional Unix implementation, I would at this point start to list the many cases where the above isn’t true. Because Unix was originally designed for uniprocessor systems, and traditional implementations are not reentrant, all kinds of caveats apply.
Of course, even in a properly designed operating system, a certain amount of cooperation among applications is required. Thread priorities are a bit like the TOS field in the Internet Protocol. If every application requests the best service, the field might as well not exist. In my opinion, user interface threads should never block on any call that does not also pump messages, and should only rarely exhaust their quantums. All cpu intensive threads should be completely decoupled from the user interface, and should run below normal priority. NT’s dynamic boosting is an attempt to encourage this configuration, but you can’t force application designers to write their software this way. If you did, you would greatly limit the flexibility of the system. There will always be that user who wants to seize the entire system (incl mouse pointer) while performing high speed data acquisition.
It is also worth mentioning that while the NT kernel was designed from the ground up to support threading and scalable smp operation, not all of the employees at Microsoft got the message. If you have ever waved one window over another, to reveal an unpainted mess, you know what I am talking about. However, this doesn’t mean that *I* have to write applications like that.
Now for a brief comment on that other OS designed from the ground up to support SMP operation. While Be never had any of the reentrancy and kernel locking problems of Unix, it is certainly no more SMP capable than NT. How hard is it to support multiple threads in win32/NT? Instead of calling MyFunc(), you call CreateThread( …, MyFunc(), …).
Of course, the real reason for BeOS’ posthumous popularity is that it was quashed by the same evil conspiracy that made Steve Guttenberg a star, and holds back the electric car.
But that’s a story for another time.
NT thread scheduling in a uniprocessor system is actually pretty simple. The highest priority thread, which is ready to run, gets the processor. If multiple threads of the same priority are ready to run, the processor is shared among them in a round robin fashion. Each thread will run for a period of time, called a quantum. Once the quantum has expired, the next same priority thread is scheduled to run.
In an attempt to increase throughput, improve the responsiveness of interactive programs, and ameliorate the effects of poorly coded programs, NT will occasionally boost the priority of a thread.
Thread scheduling in a multiprocessor system is a bit more complicated, due largely to attempts to limit FSB and memory bus contention. Generally speaking, the highest priority n threads, will run on an n-way machine. Lower priority threads may run in some cases due to processor affinity masks, which limit a thread to specific cpus. Even in the absence of application defined masks, the OS will attempt to schedule a thread on its ideal processor, or at least the last one on which it ran, because there is a good chance its working set in still in the processor’s cache.
If I were describing a traditional Unix implementation, I would at this point start to list the many cases where the above isn’t true. Because Unix was originally designed for uniprocessor systems, and traditional implementations are not reentrant, all kinds of caveats apply.
Of course, even in a properly designed operating system, a certain amount of cooperation among applications is required. Thread priorities are a bit like the TOS field in the Internet Protocol. If every application requests the best service, the field might as well not exist. In my opinion, user interface threads should never block on any call that does not also pump messages, and should only rarely exhaust their quantums. All cpu intensive threads should be completely decoupled from the user interface, and should run below normal priority. NT’s dynamic boosting is an attempt to encourage this configuration, but you can’t force application designers to write their software this way. If you did, you would greatly limit the flexibility of the system. There will always be that user who wants to seize the entire system (incl mouse pointer) while performing high speed data acquisition.
It is also worth mentioning that while the NT kernel was designed from the ground up to support threading and scalable smp operation, not all of the employees at Microsoft got the message. If you have ever waved one window over another, to reveal an unpainted mess, you know what I am talking about. However, this doesn’t mean that *I* have to write applications like that.
Now for a brief comment on that other OS designed from the ground up to support SMP operation. While Be never had any of the reentrancy and kernel locking problems of Unix, it is certainly no more SMP capable than NT. How hard is it to support multiple threads in win32/NT? Instead of calling MyFunc(), you call CreateThread( …, MyFunc(), …).
Of course, the real reason for BeOS’ posthumous popularity is that it was quashed by the same evil conspiracy that made Steve Guttenberg a star, and holds back the electric car.
But that’s a story for another time.
