Task 4

[ Class Overview ] [ Assembler Crash Course ]

Task 4: Context switching for OOStuBS

Learning objectives

Task description

The goal of this task is to implement simple process management, where the user processes control the processor release following the coroutine concept.

This will require the implementation of some functions to access the struct toc, the classes Coroutine, Dispatcher, Entrant and Scheduler, as well as the function kickoff. In addition, OOStuBS is now to get an Application.
The struct toc as well as the classes Chain and Queue, which are needed for the solution of the task, are provided as templates by us.

In order to be able to access process switching everywhere in OOStuBS, a global instance of the dispatcher should be created in part b and replaced by a global instance scheduler of the Scheduler in part c.

The functionality of the classes mentioned should be demonstrated with the help of a meaningful test program. For this purpose, a global instance scheduler of the Scheduler class should be created in the main of Task 1 and a first user process application (an object of the Application class) should be created, which in turn creates further user processes. Also test the methods Scheduler::exit() and Scheduler::kill(Entrant& item).

Implementation notes

For testing, it is recommended to divide the overall task into three parts and to start with part b and c only after part a (or b) has been implemented and tested sufficiently.

Part a

Here the coroutine switch is realized. Initially only the access functions to the struct toc and the class Coroutine have to be implemented. To test the solution, several user processes (which must be derived from Coroutine) should be created in Application (which must also be derived from Coroutine), each of which passes the processor to the next coroutine after a few instructions.

Part b

Next, the Dispatcher can be implemented. In the test program, the coroutine switch should now be able to run via the dispatcher.

Part c

Finally, the Scheduler should be added, which requires the Entrant process abstraction. In the test program, the application and user processes (now as specializations of the Entrant class) must be registered at the scheduler. Accordingly, they no longer need to know each other, because the selection of the next process can now be done by the scheduler.

Templates

We have already done the implementation of the Chain and Queue classes for you, and we also provide a part of toc.

Additional information