Application Tasks
K
A
DAK
35
3.8 Ending a Task
When a task completes its appointed function, it must relinquish control of the processor
to AMX. The AMX Task Scheduler will then give control of the processor to the next
highest priority task ready to execute.
AMX starts a task by a FAR procedure call to the task at the task start address. The task
program is, therefore, a procedure. When the task is finished, it returns to AMX in
normal end-of-procedure fashion.
A task may wish to abort execution under error conditions. The task's stack may be
deeply nested when the error condition arises. To allow a task to terminate under these
circumstances, AMX provides the ajend exit facility. Any task which calls ajend is
immediately terminated by AMX.
When a task is triggered or a message is sent to a task, the task receives a request to
execute. A task executes once for each such request. When the task ends, AMX
examines the task to determine if any additional requests for execution of the task are
pending. If outstanding requests are present, AMX flags the task as ready to run again.
The AMX Task Scheduler will then immediately start this task again. This process
continues until the task finally ends and no requests for execution of the task are present.
At that time, AMX places the task into the idle state.
If the task has received a message, AMX must perform some additional processing when
the task ends. AMX checks to see if the message came from a task. If so, AMX t ests to
see if the sender is waiting for the termination of the task just ending. If the sender is
waiting, AMX sets it into the ready state ready to resume execution.
It is possible that an application task may never end. Such a task, once started, runs
forever. For example, a task might wait for an event and then do some event -dependent
processing. Once the processing is complete, the task waits for the next event.
In this example, the task never reaches a logical end. Note, however, that the task does
become suspended awaiting an event. A task which has no logical end and which never
suspends itself is said to be compute bound.
Even if a task does wait, it is still possible that the task may effectively be compute
bound. For instance, assume that a low priority task repetitively sends a message to a
higher priority task and waits for an answer. Also assume that the higher priority task
will always provide an immediate response. In this case, the lower priority task will
always be allowed to resume after its message is sent even though a temporary
suspension does occur. The task will block all lower priority tasks.
Note
A compute bound task inhibits execution of all lower
priority tasks.