Hi,
iammisc wrote:Maybe this is a dumb question. I was looking at pros and cons of preemptive and cooperative multitasking trying to decide which type to implement in my own kernel which is kind of a cross between a monolithic and micro kernel(basic drivers such as the keyboard, console, and floppy will be compiled into the kernel while the more advanced ones will run in their own memory spaces). So my question is: Is it possible to have some tasks, such as the drivers, be cooperatively multitasked while the other user applications will be preemptively multitaksed by the os.
It's possible to combine any number of schedulers. The basic idea goes something like this:
Code: Select all
void find_next_task_to_run(void) {
TASKID task = -1;
do {
if(ready_system_tasks != 0) {
task = find_next_system_task_to_run();
} else if(ready_high_priority_tasks != 0) {
task = find_next_high_priority_task_to_run();
} else if(ready_normal_tasks != 0) {
task = find_next_normal_task_to_run();
} else {
task = find_next_idle_task_to_run();
}
} while(task = -1);
switch_to_task(task);
}
Of course it's not that simple (there's additional work for spawning tasks and deciding which tasks pre-empt which others), but it should give you the basic idea.
As for co-operative scheduling, it can have problems with CPU hogs. There's ways to prevent this though. You can limit the amount of CPU time these tasks use and reduce their priority (or change them to a different type of task e.g. "system" to "high priority", or kill them) if they exceed the limit. If you auto-detect hardware (so you know which tasks are device drivers before they are started) then you could make it so that only the kernel and device drivers are allowed to use co-operative tasks (and hope that device driver writers are smart enough to avoid hogging the CPU, which IMHO is likely anyway).
Another idea is to keep track of how much time all tasks use, so that a user can look at a list of tasks and wonder why something is using so much CPU time. If they see that 20% of CPU time is being used by a floppy driver that isn't being used much then they'd be tempted to complain (which is a good thing - the floppy driver writer will get sick of complaints and hopefully make a better driver).
The best thing about co-operative scheduling is that it can give very low latency tasks (ie. it can reduce the amount of time between a device needing attention and when it actually gets attention). If you run device drivers as normal tasks then using some co-operating scheduling is worth the the trouble because of this (without co-operative scheduling an OS like this would perform poorly as it'd take too long to respond to things).
Cheers,
Brendan
