Embedded.com - Deadline Scheduling

Embedded.com - Deadline Scheduling - Ready for a change...

Info iconThis preview shows pages 1–2. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Ready for a change? Open | Close Your ad here. Buy Media Now All Articles Products Column Courses VirtuaLabs Webinars Login | Register Welcome Guest Embedded.com Deadline Scheduling By Peter Dibble Embedded Systems Design (03/04/01, 09:31:48 AM EST) Most real-time operating systems are based on static priorityscheduling. But how can systems be truly real time without an awareness of deadlines? I have not yet used a deadline scheduler or implemented one for serious use, and I've only read a fraction of the "relevant literature." I cannot call myself a real-time scheduling expert. I am, however, an interested and half-committed neophyte. In the last few years, I've spent many weeks with real-time scheduling fanatics in the Real-Time Java Working Group and the Real-Time Java Experts Group. The Real Time Specification for Java has carefully-prepared slots for improved scheduling algorithms. They are there because the experts group wants the specification to be relevant after the real-time community moves away from static priority scheduling. There is a serious possibility this movement will happen. I started out profoundly skeptical. I have used static priority scheduling for decades and never found a scheduling problem I could not solve. More fundamentally, I, like most real-time programmers, am a control freak. I can think of too many ways a complex, authoritarian scheduler could break a system. The potential of dynamic priority is closely coupled with "write-once-run-anywhere." Priorities are all the scheduler needs to know if the only critical fact is the relative ranking of tasks. That implies that only the highest priority task has hard real-time characteristics. If there is more than one real-time task, the scheduler might serve the system better if it knows when each task needs to complete and how long it will take. In the best case, the scheduler can tell you what deadlines it can guarantee, and meet those commitments. This isn't exactly write once run anywhere, but it is the best we can expect in a real-time environment. A priority scheduler cannot make guarantees, and it may fail in unexpected ways if it is moved out of the environment for which it was designed. This may sound too positive. I am not sure dynamic priority scheduling is ready for widespread use today. It has practical problems starting with the extreme difficulty of putting a strict limit on how much processor time a task will require even in a specified environment, and ending with the NP-completeness of the general scheduling problem. It is, however, something anyone seriously concerned with real-time systems design needs to track. Some definitions We are used to fixed-priority schedulers. The term is a little misleading since priorities are not necessarily fixed. They can be freely changed under program control, but the scheduler is not allowed to change them. Aging (which I will discuss in detail later) pushes this definition, but fixed priority schedulers with aging are still considered fixed...
View Full Document

This note was uploaded on 07/16/2009 for the course SYSC 3303 taught by Professor Shramp during the Spring '09 term at Carleton CA.

Page1 / 6

Embedded.com - Deadline Scheduling - Ready for a change...

This preview shows document pages 1 - 2. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online