From: David Coleman (David.Coleman_at_roxio.com)
Date: Sun Jan 25 2004 - 17:45:22 PST
Scheduler Activations are a concept which allow combining the performance of user level thread systems with the detailed kernel knowledge available to kernel thread systems. Processors make themselves available to an address space via Activations; a thread from the ready queue can then be selected to run on that processor. When a preemption occurs, a new activation appears on that processor. Once again, a thread (possibly in the processor’s ready queue) is selected to run while the original thread’s request (for memory or I/O) is being satisfied. This minimizes waste of processor time due to preemption. Applications request the number of processors necessary and can vary those demands over the course of the execution of the program to maximize parallelism and still play well with others on the system.
This approach seems ideal for the implementation of FastThreads. It really struck me that the implementation of FastThreads wouldn’t be complete without this and the design of FastThreads really seemed to require this architecture. FastThreads was successfully implemented earlier on top of kernel threads; however, the performance numbers indicate that Activations were necessary to gain optimal performance.
One issue I have is that it seems unlikely that the user level thread system could understand the threads enough to make correct choices when choosing threads to run. It’s possible that this is simply a choice based on the concurrency model which can be chosen by the application when it chooses which thread system to link with.
Another problem lies in the combination of FastThreads and this architecture. Using local ready queues, processor reallocations would become fairly expensive. Thus the application and threading library (especially requests for processors) would have to be somewhat tuned to both the physical machine and the run-time environment. New multithreaded applications starting and stopping while others ran for long periods of time would probably incur processor allocation thrashing decrease performance significantly. Of course, in that environment, all types of applications would suffer.
I think the combination of Scheduler Activations with FastThreads would be an ideal design pattern for any concurrent programming system. I believe it would scale well from 2 processors up to a grid application. The flexibility available in FastThreads (or any user level thread system) to choose the concurrency model is very powerful. The support for preemption would also work for unreliable processors well (as long as there is recovery time to allow moving the thread and its state to a new processor).
This archive was generated by hypermail 2.1.6 : Sun Jan 25 2004 - 17:42:54 PST