Task Scheduler What is Task Scheduler ? Task Scheduler is a component of Microsoft Windows that provides the ability to schedule the launch of programs or scripts at pre-defined times or after specified time intervals. It was first introduced in the Windows 95 Plus! pack as System Agent but was renamed to Task Scheduler in Windows 98. The Windows Event Log service must be running before the Task Scheduler starts up.
Task Scheduler TASK SCHEDULER TASK EXECUTION DEVICE I/O TYPEEndless Loop No tasks. Polled OnlyBasic Cyclic Executive As often as possible. Polled Only.Time-Driven Cyclic Single frequency. Polled Only.ExecutiveMulti-rate Cyclic Executive Multiple frequencies. Polled Only.Multi-rate Executive for Multiple frequencies, at Polled Only.Periodic Tasks higher precision.Multi-rate Executive with Multiple fre at higher Polled and Interrupt-Interrupts precision.quencies, driven.Priority-based Preemptive Periodic and Non-periodic Polled and Interrupt-Scheduler tasks. driven.Deadline Scheduler Periodic and Non-periodic Polled and Interrupt-
THE ENDLESS LOOP•For very simple embedded systems, the most basic way towrite application software is as an endless loop.•The activities programmed within the loop are executed insequence.•Branches and nested loops are OK, as long as when thecode is done executing, it loops back to the beginning foranother go-round.
Example (in pseudocode) :DO FOREVER Request Input Device make a Measurement Wait for the Measurement to be ready Fetch the Value of the Measurement Process the Value of the Measurement IF Value is Reasonable THEN Prepare new Result using Value ELSE Result will be an Error Report Request Output Device deliver the Result Wait for the Result to be output Confirm that output is OKEND DO
•In some simple embedded systems this style ofprogramming works well, especially if the software cancomplete the sequence of code and loop around quicklyenough.•But in other embedded systems, this style of programmingwill result in performance that is too slow.•Keep in mind that interrupts from hardware devices can notbe handled in this style of programming.•Devices are polled, if they are to interact with software in theloop.
BASIC CYCLIC EXECUTIVE In more complex embedded systems, the idea of theendless loop can be extended.There are hundreds or thousands of lines of code in thesesystems, and so software designers like to organize the codeinto separate units referred to as „tasks‟.These tasks (sometimes also called „processes‟) should beas independent as possible so that they deal with separateapplication issues and interact very little with one another.
In a software design using a basic cyclic executive, thesetasks execute in standard sequence within an infinitely-repeating loop.This is much like the endless loop design, but now dealingwith large „tasks‟. It is sometimes called “round-robin”scheduling.
These tasks can pass information to one anothereasily, by simply writing and reading shared data. That‟s because every task always runs to completionbefore another task begins running. So there‟s no danger ofa task getting incomplete data from another task. Here too, interrupts from hardware devices can not behandled in this style of programming. Devices must bepolled, if they are to interact with tasks in the loop. In some sense, this can be thought of as “real-time”task scheduling, if all of the software in the loop executesquickly and the loop can execute repeatedly at a very rapidrate.
TIME-DRIVEN CYCLIC EXECUTIVE For some applications, the view of “real-time” taken bya basic cyclic executive is not precise enough. A basic cyclic executive tries to run its tasks as quicklyand as often as possible. But in more sophisticated applications, precision oftiming is often more important than raw speed. A time-driven cyclic executive can begin to addressthis requirement. In this scheme, one hardware timer interrupt is used totrigger the execution of all tasks.
The tasks execute one after another, each onerunning to completion before the next one begins. For a time-driven cyclic executive to work correctly,the final task in the chain of tasks must complete itsexecution before the next timer interrupt arrives. The rate of hardware timer interrupts is the rate atwhich the tasks must execute.
Although there is a hardware timer interrupt involvedhere, tasks can still pass information to one another easily,by simply writing and reading shared data. Every task runs to completion before another taskbegins running. Interrupts from hardware devices (other thanthe timer) can not be handled in this style of programming.Devices must be polled, if they are to interact with tasks.
MULTI-RATE CYCLIC EXECUTIVE The time-driven cyclic executive assumes that alltasks need to run at the same rate of repetition. But in some applications, different tasks may need torun at different rates. A modified time-driven cyclic executive, called themulti-rate cyclic executive, can handle this need reasonablywell in cases where a higher rate is an integer multiple of the„base‟ rate.
The idea is simple: In a multi-rate cyclic executive, thebase-rate tasks run once per timer interrupt, and a higherrate task runs a number of times per timer interrupt. That number is the integer multiple of the base rate. And the repeated executions of the higher rate taskshould be as equally spaced as possible within the sequenceof tasks following a timer interrupt. Often the base-rate period is called the “major cycle”,and higher rates identify socalled “minor cycles”.
The example illustrated here shows a system of 10 tasks thatexecute at the base rate (e.g., 10 Hz, if the timer delivers 10interrupts per second).In addition, there is an eleventh task marked by a star, whichexecutes at 40 Hz, 4 times the base rate.This is done by having the starred task appear 4 times in the
LIMITATIONS OF CYCLIC EXECUTIVESThe limitation that hardware devices must be polled whenusing a cyclic executive is often a serious one.If the device is not polled frequently enough, transientoccurences of importance might be missed.If the device is polled too frequently, much of theprocessor‟s power might be wasted on execution of thedevice polling software.For these reasons, interrupt-driven peripheral devices areusually preferable for I/O.
Another objection to cyclic executives is that the timing ofexecution of a task can not be controlled precisely. Even when hardware timing is used to trigger theexecution of a chain of tasks, only the first task in the chainhas its start time determined precisely by hardware. The second task in the chain starts to run wheneverthe first ends, and so on. If these tasks contain code of varying processorloading such as data-dependent loops.. all later tasks in the chain will run at times influencedby load on previous tasks. So precise timing of tasks along the chain of taskscannot be controlled.
Even if all tasks do not contain code of varying processorloading, timing of individual tasks is only approximate.This can be seen in the illustrated example of the multi-ratecyclic executive.In that diagram, the starred task is required to execute at arate of 40 Hz. In other words, there should be precisely 25milliseconds (or 25,000.00 microseconds) betweensuccessive execution starts for the starred task.If the diagram is viewed as a circle where a completecircumference represents one 10 Hz base period, then thestarred task should execute at angles of precisely 0o, 90 o,180 o and 270 o.But it does not. Sometimes it executes somewhat early.Sometimes, a tad late.
It all depends on when the previous task finished, and howlong the following task will be.Remember, each task must run to completion and cannot be“interfered with” in mid-execution.Some software designers have in the past decided to solvethese timing problems by actually counting machine cycles ofthe computer instructions to be executed by each task, inorder to figure out precisely how long each task would take.Then the designer would determine exactly how much of acertain task could execute before a precisely timed taskneeded to run.This part of the task would be allowed to run, and then theprecisely timed task would be inserted for execution, and theremainder of the delayed task would run later. Effectively, the
But this “solution” itself gives rise to several new problems:(a) If the tasks involved in a mid-task switch share some datastructures, those data could end up in an inconsistent statebecause of the mid-task switch. This could result in anumeric error in the outputs of either of the tasks involved.(b) Every time that software maintenance causes some codeto be changed or added in the tasks which run before themid-task switch, machine cycles need to be re-counted andtask timings recalculated.
A task might need to be cut apart differently for the mid-taskswitch in this new code situation.In other words, this “solution” is in itself an error-prone andexcruciatingly tedious method of building software.So rather than offer it as a “solution”, this should be offeredas anexample of an attempt to use a cyclic executive beyond itsrealm of usefulness.Cyclic executives should not be used in situations wheretiming requirements are so precise and critical, that there isthought of “surgically” cutting a task into two sections.
MULTI-RATE EXECUTIVE FOR PERIODIC TASKSIf all tasks are periodic, but at differing rates of execution,then a multi-rate executive can often be better than a cyclicexecutive. In such a scheduler, timer interrupts must be delivered at arate which is the lowest common multiple of all the rates ofthe tasks. And ateach timer interrupt (or „tick‟), tasks can bemade to execute.For example, if tasks need to execute at 50 Hz, 60 Hz and100 Hz, then timer interrupts must be delivered at a rate of300 Hz. The 100 Hz task will be made to execute on everythird tick.The 60 Hz task will be made to execute on every fifth tick.
If tasks do not need to be time-synchronized with each other,then they could be executed at ticks which are offset fromone another.For example, the 3 tasks above need not all be run at ticknumber zero.Perhaps the 100 Hz task would be run for the first time at tick#0; and the 60 Hz task at tick #1, and the 50 Hz task at tick#2.A simpler example is shown in the illustration below.Here we have only 2 rates, with the higher rate or „minorcycle‟ being four times the lower rate or „major cycle‟.
Every task must run to completion before another taskbegins running.As with cyclic executives, tasks can pass information to oneanother easily, by simply writing and reading shared data.All hardware devices (other than the timer) must be polled.
CAUTION: ADDING INTERRUPTSThe restriction to polled hardware devices in all the previous types ofschedulers, is a serious restriction.Modern hardware I/O devices are typically interrupt driven.But interrupt driven devices can cause problems of their own, if they arenot handled properly in software.Very often, if an interrupt service routine (or „ISR‟) tries to pass data to thevery same task it is interrupting, the task may not handle the passed dataproperly.For example, a task may begin processing some data and then aninterrupt service routine might update the data, followed by the taskreading the data again for purposes of further processing.The net result would be: Part of the data processing in the task is doneon an old data value, and another part is done on a new data value,resulting in possible inconsistent outputs from the task.
Another example is a situation of a task and an interrupt service routinecommunicating through a shared data table. If an interrupt occurs and is serviced while the task is in the midst ofreading from the table, the task might well read „old‟ data from part of thetable and „new‟ data from other parts of the table.This combination of old and new data might well be inconsistent, andmight well lead to erroneous results.Hence, the integration of interrupt-driven software with task schedulersrequires special care, particularly in terms of information exchangebetween ISRs and tasks.
MULTI-RATE EXECUTIVE WITH INTERRUPTSOne clever idea for avoiding the pitfalls we have seen when ISRs andtasks interact, is to have the ISRs write their input data into one set ofbuffers, and the tasks use data from a completely separate set of buffers.At every clock tick (of the multi-rate executive for periodic tasks, forexample), interrupts are turned off and input data are copied from the ISRbuffers to the task buffers.Then interrupts are turned back on, and the tasks scheduled for that tickare permitted to execute.
This kind of scheduler becomes quite complex, and should not be writtenas a weekend "garage” project.With this scheduler, every task runs to completion before another taskbegins running. As with previous kinds of executives, tasks can pass informationto one another easily, by simply writing and reading shared data.Hardware devices are no longer restricted to polled only. They can be interrupt-driven. However, it is important to note thatinformation delivered by an interrupt and acquired into software byan ISR, is not immediately passed onward to a task for furtherprocessing ISR
GETTING FASTER RESPONSE: PREEMPTIVESCHEDULINGThe schedulers which have been surveyed so far are called“non-preemptive”, because switching between tasks onlytakes place when one task has fully completed its executionand another task wants to start its execution (from itsbeginning).Faster response can often be obtained by going over to a“preemptive” scheduler.With a preemptive scheduler, switching between tasks cantake place at any point within the execution of a task. (Evenwhen the task isn‟t yet done executing its code.)
For example, when an interrupt occurs its ISR might want tosay something like “I don‟t care which task was executingbefore my interrupt, and I don‟t want to wait for the next timertick. I would like Task #67 to begin executing right now!” Apreemptive scheduler can dothis.
However, a preemptive scheduler is orders of magnitudemore complex than any nonpreemptive scheduler.And such a scheduler gobbles up lots of RAM memory forstorage of task “contexts” and other task status information.Such a scheduler could not be written in a month of Sundaysas a “garage” project.Some commercially available real-time operating systemsoften have preemptive schedulers as their underlying“engines”.With a preemptive scheduler, hardware devices can be eitherpolled or interrupt-driven.Information delivered by an interrupt and acquired intosoftware by an ISR, can be immediately passed onward to a
CAUTION: PREEMPTIVE SCHEDULERS BRING UP NEW ISSUESPreemptive schedulers offer the software developer many benefits,beyond what can be achieved with simpler “home-made” schedulers.But their sophistication brings up new issues, of which a softwaredeveloper must be aware.The first issue which a software developer must consider is: Which tasks should a given task be allowed to preempt if theyare running, and which tasks should a given task not be allowed to preempt ?The answer to this question is given by assigning a priority number toeach task. Tasks of higher priority can preempt tasks of lower priority. But tasks with lower priority can not preempt tasks of higher priority. A preemptive scheduler needs to be told what is the priority of
A second issue that a software developer must consider is: Tasks whichcan be preempted and which can preempt others, cannot be allowed topass information to one another by simply writing and reading shareddata. Simple methods for passing information between tasks which worked for non-preemptive schedulers, no longer work for preemptive schedulers.The problem in passing information between tasks by writing and readingshared data when using a preemptive scheduler, can be seen as follows: If one task preempts another while the second task is in the midst of reading from a shared data table, the second task might well read „old‟ data from part of the table and „new‟ data from another part of the table, after the first (preempting) task writes new data into the table.This combination of old and new data might well be inconsistent, andmight well lead to erroneous results.
This is in fact the same problem that occurs if an ISR and a task try tocommunicate by writing and reading shared data, as shown earlier.
In order to help the software developer prevent these problems whentasks try to share information, an operating system that has a preemptivescheduler needs to also provide mechanisms for passing informationbetween tasks (and also to/from ISRs).The specific mechanisms provided are different in different operatingsystems. For example, the pSOSystem real-time operating system provides message queues, counting semaphores, event flags, notepad registers and asynchronous signals. Operating systems meeting the OSEK standard for automotive RTOS‟s provide “Resources”, “Events”, “Alarms” and “Messages”. The Wind River VxWorks real-time operating system offers message queues, pipes, semaphores, mutexes, asynchronous signals; but it does not provide an event flag mechanism.
Whereas the OSE operating system, which emphasizes high-availabilityin distributed multi-processor environments, relies primarily on messagesfor communication between tasks (but it refers to them as “signals” forcommunication between “processes”). These mechanisms must be used every time information is to be passed between tasks, in order to ensure reliable delivery of that information in a preemptible environment.
DEADLINE SCHEDULINGUsers of off-the-shelf priority based preemptive schedulers sometimeshave the following objection:“Where do I tell the scheduler what are the deadlines for my tasks, so thatthe scheduler will make sure they‟re met??”.The fact of the matter is that you can‟t tell these schedulers about taskdeadlines. They don‟t want that kind of information. All they want to be told is each task‟s priority; and then they do their task scheduling based on the priority numbers.The mapping between deadlines and priorities is not oftenstraightforward.In fact, it‟s most often downright impossible to be sure that tasks willmeet their deadlines if you use a priority based preemptive scheduler with
An alternative kind of preemptive task scheduler is called a “DeadlineScheduler”.This kind of scheduler tries to give execution time to the task that is mostquickly approaching its deadline.This is typically done by the scheduler changing priorities of tasks on-the-fly as they approach their individual deadlines.The popular commercially-available off-the-shelf real-time operatingsystems don‟t offer deadline scheduling.