Skip to content

Problems With Tasking

April 17, 2009

I’ve been doing some work recently converting the filesystem to run as a separate kernel task. (Apart from fitting in with the general design philosophy, this makes the control and scheduling of access to the disk much easier.)  Once I’d sorted out some memory allocation errors this runs fine, but it did highlight a subtle bug. The current tasking code searches through the list of tasks to find the next ready one, and switches to it. If there is no other ready task, it tests to see if the current task is ready to run; if not it issues a “hlt” instruction. This stops the processor until it receives an interrupt. The theory is that this saves the processor from running when it doesn’t need to.

Unfortunately, there is a problem when there are no ready tasks at all (which, in practice, happens quite a lot). The processor will halt in the timer interrupt routine, and then be awakened by the next interrupt. If this next interrupt is a timer one, we get nested interrupts – let this happen long enough (not very long!) and we end up with an ever increasing stack and an eventual triple fault. The problem is that the timer interrupts are never returning.

A very simple fix to this problem, which I have implemented, is to end the intitial task (”tas1.c”) with an infinite loop. Thus there is always at least one task ready to run at all times. But this isn’t very elegant, or very efficient.That initial task will always be taking a share of the processor time, even when there are plenty of useful tasks running. It seems to me that the best solution is to have two task lists – a high priority one and a low-priority one. Tasks on the low-priority list will only get to run if there are no ready tasks on the high-priority list. Thus we can create a low-priority task that is simply an infinite loop and always have a low-priotity task ready to run.

This still isn’t very elegant (although the idea of multiple levels of priority is obviously a good one). There must be a more direct solution to the initial bug – it just needs a little thinking about! Also, it occurs to me that the task lists should only contain the tasks that are ready to run. This would speed up the search for the next ready task. Something further to think about.

From → IanOS

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: