Please note that we really don't want *all* processes to get preempted. It is convenient most of the time that you don't get preempted by processes at the same priority, because it usually allows you to do without locks. Processes should have to register if they want to be shuffled by the shuffler.
By the way, what priority should the processes get toggled to? Perhaps the register method should have a parameter for the desired lower priority.
One final note: multiple schedulars running in the same image is bound to cause trouble, and yet, but is there any one schedular that will make everyone happy? Why do people want preemption at all, by the way?
-Lex
Tim Rowledge tim@sumeru.stanford.edu wrote:
The canonical example of this is simply a high priority loop waiting on a Delay. Each time the Delay fires it will stir up the process list at the priority of the suspended process (and by extension any other priority level that might get involved) assuming of course that the suspend is implemented to add the suspended process at the back of the list. Not all systems actually do that - VW used to put it at the front of thelist and so the same process would get resumed. Might still be like that for all I know.
I think there is all the VM support you need already there, what with the Delay etc. Note that checkForInterrupts is already involved since it is the mechanism by which the Delay termination is noticed!
I imagine that it might be useful to add some VM support to directly deal with a special timer for process stirring and thereby reduce by a small amount the allocating and setting up of actual Delay objects, but it would be a pretty minimal improvement I suspect. tim
-- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Never write software that anthropomorphizes the machine.