CS452 - Real-Time Programming - Winter 2016

Lecture 22a - Destroy

Public Service Annoucements

  1. Train Control I demo on Friday, 3 July.
  2. The exam will start at 12.30 on 19 April, 2016, and end at 20 April, 2016.
  3. Bugs fall into two categories
    1. Ones that have code that works around them while the demo continues.
    2. Ones that require reprogramming.
    Causes of bugs are of two kinds.
    1. Computation bugs
    2. Hardware bugs
    An example of a hardware bug that should have code to handle it is a malfunctioning switch or sensor.


7. Housekeeper

Housekeeper of the system who will detect, and possibly clean up pathologies.

8. The Grim Reaper

Most often pathologies are handled by destroying one or more tasks, the recreating them. Destroying is usually done in the context of programming conventions. One convention followed here is that when tasks work together as a unit task creation is done internally with one master task directly or indirectly creating all tasks in the unit.

What should Destroy Do?

The first part of Destroy is ensuring that the task(s) to be destroyed never execute again. To do so we need a little more than you did for Exit( ) in the first part of the kernel.

The amount of work to be done is limited by the number of tasks in the system.

Resources must be returned for reuse. This part of task destruction can require significant computation, so it is usually handed off to a low priority task. Here are the things that must be done.

The task's ownership of the latter two resources are not necessarily known to the kernel. How can they be returned? (In the case of hardware, "returned" means be put back into its unowned state.)

Ownership of resources about which the kernel has no knowledge means that the obvious implementation

  1. Some task, most likely the idle task, notices that a service is not being performed, probably by noticing that a sendQ is growing too long.
  2. The detecting task kills the broken task using a non-blocking Kill system call.
  3. Executing the system call the kernel does the Exit() part of the system call and reclaims the kernel resources. Presumably the kernel maintains the creation tree to find the descendants quickly.
  4. When the detecting task runs again it cleans up any other resources.
This does not work, because there is no reason why the detecting task would know what needs to be done.

Here is a less obvious way of arranging destruction.

  1. The detecting task sends a message to the broken task asking it to committ suicide.
  2. The task has a suicide case that returns all its resources, running code such as appears in the destructor of an object. It then calls the Suicide() system call and the kernel completes the job.
There are a few good reasons why this solution might be unsatisfactory.


Return to: