From: Reid Wilkes (reidwilkes_at_hotmail.com)
Date: Wed Jan 28 2004 - 09:07:07 PST
This paper describes a mechanism called "Scheduler Activations". The basic problem being addressed is how to best implement threads. The paper starts by presenting the two major alternatives commonly employed: using the notion of threads supplied by the kernel or using threads entirely implemented in user mode. Both options in their pure form have some serious drawbacks. Kernel threads are inherently slow; any thread control operations have to pass between user mode and kernel mode, which imposes a huge performance hit due to parameter checking and copying, etc.... User mode threads, in comparison, are incredibly fast. Their drawback, however, is that the user mode threading system is in reality implemented on top of a single kernel thread. So the kernel scheduler does not necessarily allocate machine resources (i.e... processors) to the user mode threads in a fair way. Furthermore, whenever that underlying kernel thread is blocked on an IO request initiated by any of the user mode threads, all user mode threads running on that kernel thread are then blocked. This means that no useful work can be done by the application while waiting for asynchronous IO. The paper proposes a system which retains the performance of user mode threads while fixing the problems described by allowing the user mode thread scheduler and the kernel to communicate about resource allocation decisions. The mechanism described to enable this coordination between kernel and user mode thread library is the "Scheduler Activation". Not having a great understanding of how threading and kernel transitions are implemented in any system, I found the description of the activations a little lacking. The basic principle was clear enough, but there seemed to be a lot of hand-waving going on under the covers that I couldn't quite understand. Essentially, it seems that there are two purposes two a scheduler activation... in one sense it is the vehicle by which the kernel communicates with the user mode thread scheduler; in another it is the abstraction of a processor used at the user level thread scheduler. The thread scheduler can now actually make decisions on how to deploy thread across multiple processors if they are available rather than simply multiplexing user threads on top of an underlying kernel thread. The kernel must notify the user level scheduler about significant events such as thread preemption, blocking, and resumption. These notifications allow the user level scheduler to really be able to make fully informed choices, such as moving a high priority thread off of a blocked scheduler activation to another unblocked activation. One interesting (and appealing) part of the design here is that the user level does not, in the limit, control the processors. The kernel still has complete authority and autonomy in allocating processors and processor time as it sees fit. However, because the kernel is responsible for telling the user mode scheduler about how many processors it is being given at any point in time, the user scheduler can adapt accordingly to it current set of resources. Overall, I thought this paper proposed a very exciting idea. I am curious to know if there has been any further work along these lines in the commercial arena. I am always hesitant to agree with an idea which adds too much conceptual complexity to a system (and this definitely does add complexity), but one mitigating factor with this system is that the complexity is added entirely in the kernel and the user level thread scheduler. The vast majority of users and programmers of a system never even know that this technnology is being employed under the covers.
This archive was generated by hypermail 2.1.6 : Wed Jan 28 2004 - 09:07:18 PST