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.)
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!
Plane oops http://xs.to/thumb-AF83_4B54A285.jpg
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