MAINTAINING THE EXECUTION HISTORY OF A TASK

Tracking the execution history of the task set is useful for reviewing how tasks were scheduled after execution has completed. A user can view more detailed timing statistics such as when a job was scheduled, for how long, and how a job completed for any task since the SRMS system started.

DESCRIPTION OF AN execHistory STRUCTURE:

Each task (task_struct structure) contains a task_history structure named execHistory as specified in the srms.h header file. The task_history structure contains a pointer to an array of job_exec_history structures. The length of this array is defined by the MAX_HISTORY value which is set to 500 by default in srms.h. Each entry in this array pertains to one instance that a job gets scheduled. For example, if a job gets preempted 10 times before its period completes, then the execution history of that job will occupy 10 entries in the array. The value of MAX_HISTORY means that the scheduler will record the execution history of the first 500 times that the task gets scheduled. After 500, the array wraps back to zero, so results may be misleading. The programmer should modify this value depending on the intended use of the system.

Memory storage for this array gets allocated when a task registers with the system for the first time. The function initialize_task() is called from set_SRMS_rtparams() to reserve space for MAX_HISTORY entries in the task's execution history array. Also, each task_history structure contains an unsigned integer value called last_index which points to the first unused index in the array. Initially, this value is zero. 

RECORDING THE EXECUTION HISTORY OF A TASK:

Each time a job gets scheduled, the SRMS scheduler begins record keeping in a new entry in the execHistory array starting at the index pointed to by last_index. Just before a job get scheduled, its start time (relative to the SRMS scheduler start time) is recorded using Win32 API function timeGetTime(). Also, the time remaining in the task's budget and the execution time remaining are recorded as well. Next, the scheduler releases control of the processor to the job. When the it resumes, the scheduler immediately records the job's end time with timeGetTime().  It also uses Window's higher-resolution counter to more accurately compute the total time that the job spent executing and records that value in the dJobElapsed field. Once completed, the last_index value is incremented. At each job's deadline, more record keeping is performed on the job's periodic performance with the help of the record_job_results() function. The status field is filled with a character indicating the completion status of a job.  This value could be one of four characters depending on if the job met its guaranteed deadline (*), missed its guaranteed deadline (=), met a non-guaranteed deadline (+), or missed a non-guaranteed deadline (-). Once finished with record keeping for the last job, the scheduler tries to admit the task's next job by calling admit_next_job(). This function contributes to the job's execution history by recording any timing discrepancy between when a job should have been ready and the actual current time using timeGetTime(). It also records the amount of time that the SRMS scheduler wasted while waiting for a task to reply with its next job's expected execution time.  This is stored in the communication_wait field of the job_exec_history structure. Next, the admit and reject functions fill the admit_reject entry with an 'A' or an 'R' to indicate whether a job is admitted or rejected.

EXPORTING THE EXECUTION HISTORY OF A TASK:

All of this information gets processed by the export_history() function after the user selects 'Export Task History' from the File menu. It creates a tab delimited text file, whose default name is 'history.doc' as defined in srms.h. The function reformats the information neatly into a table and presents more insight into the execution of the task set. The example below presents a sample of an exported task history. Values in the 'Period' column reflects the beginning of a task's period in milliseconds.  If a job gets preempted during execution, then the next time that the job is scheduled, this column's value displays a dash '-' indicating that the job is still executing in the same period. 'Disc' is the discrepancy in milliseconds between when the task should have been ready and when it was actually ready, according to the SRMS scheduler. 'Start' and 'End' display the times recorded for the start and end of that job's portion of execution. 'Exec' shows the job's execution requirement while 'ExLeft' shows how much the job needs to execute before reaching its execution requirement. 'LeftOvr' reflects how much time gets passed on to this job from the excess time in the budgets of higher priority tasks. The 'A/R' column tells whether a job is accepted or rejected. If dual priority is enabled, then this column also indicates whether a job is scheduled at a high or low priority compared to other real-time tasks. The  'RealElap' column displays how much real time elapsed between when the SRMS scheduler released the processor and when the scheduler regained the processor. The final column 'Stat' displays the completion status of the job, as described above.

One more final note, the export_history() function outputs the execution history of all tasks that were at one point active and registered since the SRMS application started.  It first outputs execution histories for all currently active and registered tasks (found in the task_list) and then traverses the unregistered task list (unregistered_task_list) for any tasks that previously unregistered.

SAMPLE EXECUTION HISTORY OF A 3-TASK SYSTEM:

---------------------------------------------------------------------------------
E:\Project\task2\Debug\task2.exe
Process 132, Thread 96
Period = 2000 msec
QoS achieved = 100., minimum QoS requirement = 75.
Met Deadlines = 8, Missed Deadlines = 0
Met Guaranteed Deadlines = 7, Missed Guaranteed Deadlines = 0
Total Guaranteed Deadlines = 8

---------------------------------------------------------------------------------
E:\Project\task3\Debug\task3.exe
Process 190, Thread 167
Period = 5000 msec
QoS achieved = 100., minimum QoS requirement = 70.
Met Deadlines = 3, Missed Deadlines = 0
Met Guaranteed Deadlines = 3, Missed Guaranteed Deadlines = 0
Total Guaranteed Deadlines = 4

< Back to the SRMS Service Home Page >