On Apr 13, 2010, at 2:18 PM, Chris Muller wrote:
On Tue, Apr 13, 2010 at 2:53 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Apr 13, 2010 at 12:05 PM, Chris Muller asqueaker@gmail.com wrote:
Hi, I'm not very well-versed in process-scheduling, but I'm having trouble understanding why you don't like sending the last pre-empted process to the back of its queue of processes waiting at that level. Doesn't that seem more "fair" and also, allow "smoother" multi-tasking since those other processes at that level would get a turn?
Your reason was: "It means one cannot rely on cooperative scheduling within a priority level." but I don't understand what you mean by "rely on"?
A cooperative scheduler is one in which it is guaranteed that another process does not run until the active process chooses to yield. This makes it easy to implement particular forms of synchronisation because processes are not preemptive. The Smalltalk scheduler is a form of real-time scheduler in which processes have fixed priorities and are only preempted by higher-priroity processes. This also makes it easy to implement various kinds of multi-process behaviour because one is guaranteed that a lower-priority process is never running while a higher priority process is able to run.
Ok, I am guessing this is useful for time-critical applications; like a voip chat program. So it can choose to not be interrupted while actively digitizing voice, perhaps..
If you have some task that is clearly higher-priority than some other task (eg: VoIP vs. polling an email server), then it's better to simply use a higher-priority Process rather than relying on particular scheduling behavior within a single priority-class.
Cheers, Josh