A Thread Scheduler for an Real Time Embeded Operating System.

Question

I have been given the task to fix an Embedded Operating System which is written in C/C++. The Current thread scheduler being used is very similar to Round Robin Scheduling, except it lacks one very important feature, the ability to interrupt threads and then return executing thus creating a dependable "slice" of execution time.

My Question is, how does one go about interrupting running code, execute another task and then return execution gracefully? I believe this behavior requires assembler specific to the architecture. This is the chip that the OS will be running under: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC860

On a side note, this is avionics software so it must be "Deterministic". Apart of this is that there is no heap usage, all memory must be bounded.

The current system is a "periodic process" in which the next task must wait for the first to complete. This is simple horrific, if one part of the operating system crashes, lets say the ATN stack, then the entire operating system will be brought to its knees. (Insert crashed airplane here... although this is class B software, which means the airplane will not crash if the system does.)

Answer 1

If this is an operating system, really an operating system, of course it's talking to the hardware. It must have interrupt handling going in order to deal with I/O devices.

Sometimes the timer interrupt will come from the CPU itself, but in other system architectures it will come from an IO controller or some other device.

A general design alternative is to hand out CPU time only in small quanta so that the scheduler can reconsider more frequently, but no one can tell from here if that is going to make your particular problem better or worse.

So there's really no way anyone is going to be able to give you a detailed prescription here.

Except, of course, to report your employer to the FAA.

Answer 2

disclaimer: Don't use my advice. Find a specialist, if people's well-being depends on a system then don't leave it to chance/hacks/SO advice!

You should be able to write a new procedure which is entered via an interrupt at a known interval, save thread-state using existing scheduling functions and change thread context. Also,ensure your locking primitives work with the new scheduling and that you don't balls up non-atomic/non-instruction based T&S locking or anything.

This website gives good information about thread switching, state saving and so on. Ultimately interrupts are specific to your CPU/Hardware. The way you save your thread state will also be dependent on the constraints of the system and the thread structure you are using.

Modern Operating Systems 3rd Edition contains some good chunks on the theory, but the implementing depends on existing code and best practice for the hardware you are on, as well as other code in the kernel that handles interrupts, signals and so on.

Also "Real-time systems design and analysis By Phillip A. Laplante" might be a good resource for adapting your existing scheduler to the new requirements. Another interesting bit of text

Answer 3

If I read your question correctly, I think you want to add thread priorities to your scheduler. Schedule all threads of the same priority round robin, but allow a higher priority to preempt a lower priority thread.

You must already have facilities for saving and restoring a thread's context to to round robin time slicing.