Admitting a New Task
Once the QoS admission thread finds a task whose QoS
requirements can be met, it immediately sends the SRMS scheduler thread a WM_AdmitNewRTtask
message. The LPARAM value of the message is actually a pointer to the task
structure in either the request or the await queues. The arrival of this message
immediately awakens the SRMS scheduler from its wait
state, and it then calls admit_new_system_task() with the task pointer as its
only parameter.
Initially, the admit_new_system_task() function needs to determine which
waiting queue the task to be admitted is currently residing. Remember, the function only
knows the task's address in memory, not what queue it is in. Therefore, the first order of
business for the function is to use the find_task() function to determine the
task's location. find_task() takes as parameters a thread id and a special
list/queue identifier telling it where to look for the task. If it finds the task in the
specified location, then a pointer to the task is returned or else NULL. admit_new_system_task()
first looks for the task in the request_queue and then continues to search
the await_queue if it could not be found. Once located, it removes the task
from its waiting queue using remove_task(). remove_task() is a
special function that only removes a task from a list or queue while still preserving the
space it occupies in memory. Therefore, immediately following its removal, the task is
inserted into the SRMS system task list using insert_system_task(). This
function inserts a new task into the system's active list of tasks (task_list)
and rate monotonically orders the new list by period.
If the SRMS scheduler has not yet been started, then the task thread is sent a WM_QoS_Admission_SucceededMsg
message along with its estimated QoS value notifying it that QoS admission succeeded.
Win32's PostThreadMessage() function is used rather than SendMessage()
because it sends the message directly to the task thread's message queue and not the
thread's default message handler [Bypassing the default message handler makes
communication faster and more direct; refer to the real-time
task model for more information]. Lastly, just before returning, admit_new_system_task()
sets the hNewTaskAdmittedEvent handle to signaled, which alerts the QoS
admission thread that the task has been successfully added and that it can continue with
QoS negotiations. At this point, the addition of the new task into the SRMS system is
complete.
Otherwise, the SRMS scheduler is active and the function needs to determine a safe and
convenient ready time to schedule the task. It tries to make the task's ready time equal
to the highest priority real-time task's next deadline. If the new task becomes the new
highest priority task, then it uses the deadline of the next highest priority task. The
new ready time is then assigned to the task's deadline and super-deadline and its budget
is filled up to its allowance. Next, the thread's priority level is set to the same
priority level of the other active system tasks and its NT priority boost capability is
disabled. Following this, the task gets sent a WM_QoS_Admission_SucceededMsg
message along with its estimated QoS value notifying it that QoS admission succeeded. Then
the task is sent a WM_SystemStartTimeMsg message with the system start time
as the LPARAM value. Although the task only uses this value for debugging
purposes, the await_system_start() function in the SRMS API requires this message as the final step just before
scheduling. Finally, admit_next_job() is called to try and admit the new task's first job.
Just before returning, admit_new_system_task() has two small housekeeping
jobs remaining. First it calls UpdateDialogBoxes() to update any dialog box
that is currently active in the SRMS service's GUI. Since a new task has been admitted,
the new task set needs to be displayed in either the View or Remove Registered Tasks dialog boxes. Secondly, the hNewTaskAdmittedEvent
event object handle is signaled, thereby alerting the QoS admission thread that the task
has been successfully added and that it can continue with QoS negotiations. At this point,
the addition of the new task into the SRMS system is complete.