10 Multitasking

8/10/2019 10 Multitasking

1/40

COMP200 1

Multitasking


2/40

COMP200 2

Outline

Introduction to Multitasking

Pre-emption and Scheduling

Kernel structure

Tasks

WASM directives

The Handler

The Dispatcher

Setup Code


3/40

COMP200 3

Introduction to Multitasking

Most operating systems allow more than oneprogram to be running at a time.

This is achieved by sharing the CPUs timebetween the tasks that are ready to beprocessed.

The CPU executes each task for a shortwhile.

In a working system this all happens so

quickly that it appears that tasks are runningconcurrently.


4/40

COMP200 4

Multitasking Diagram

Task 3

Task 2

Task 1

CPU

The CPU executes Task 1 for a whileThen Task 2Then Task 3

Then Task 1Then Task 2And so on

CPU time is shared between the three tasks.


5/40

COMP200 5

Multitasking Kernel

We call the piece of code that facilitatesmultitasking a Multitasking Kernel.

This code is right at the heart of a multitaskingoperating system.

A multitasking kernel allows each task to bewritten as if it has its own CPU to run on.

The multitasking kernel allocates the CPU to

different tasks in turn.


6/40

COMP200 6

How do we share the CPU?

Two main approaches: Cooperative Multitasking

Tasks voluntarily release the CPU after doing someprocessing.

Maybe when they are waiting for I/O.

Maybe when they terminate.

But with this approach tasks can hog the CPU. Preemptive Multitasking

Tasks are given a limit on how long they can use the CPU forat a time.

All tasks will get a go on the CPU.

We will only consider Preemptive Multitasking


7/40

COMP200 7

Preemptive Multitasking

The length of time a task is given is called itsTimeslice.

We can give higher priority tasks longertimeslices.

If a task terminates, or requires a resourcethen the kernel may end its timeslice early.


8/40

COMP200 8

Scheduling

The multitasking kernel must decide which taskwill use the CPU next?

This process is called Scheduling. A simple scheduling scheme would be to simply

go through each task in turn.

More complex scheduling schemes might takeinto account things like The assigned priority of the task

The likely time until the task will complete

The nature of the task (e.g. interactive, background)


9/40

COMP200 9

Saving/Restoring Context

When a task is taken off the CPU we must makesure we can resume execution at a later time.

Our multitasking should not interfere with this program inany way.

This involves saving information including.. The General Purpose Register contents.

The address of the instruction we were up to. This procedure is known as Saving Context.

It generally involves saving these values to memory.

Before this task can be resumed we must restorethe context.


10/40

COMP200 10

Multitasking Kernel Parts

Setup code.

Setup exceptions, as well as the tasks.

Handler. Determine the cause of the exception.

If the timeslice is over then go to the Dispatcher.

Dispatcher. Save the context of the current task.

Determine which task should run next. (Scheduling)

Load the new tasks context and resume executing it.

Tasks.

These are the user tasks.


11/40

COMP200 11

Multitasking Kernel Parts

Our multitasking kernel system will consist offour main parts

Setup code.

Handler.

Dispatcher.

Tasks.


12/40

COMP200 12

Kernel structuremain:

# Setup tasks.

# Setup interrupts.

# Go to the first task.

handler:

# Check which exception occurred.# If it is the timer interrupt then we

# jump to handle_interrupt.

# Otherwise we jump to the system.

# exception handler.

handle_interrupt:

# Acknowledge the interrupt.

# Subtract 1 from the timeslice counter

# If timeslice counter is zero then goto dispatcher

# Otherwise we return from exception.

dispatcher:

# Save context for current task

# Select the next task to run

# Set the timeslice counter to an appropriate value

# Load context for next task

# Continue with next task


13/40

COMP200 13

Kernel structure (cont)

task1:

# Code for task1

task2:

# Code for task2

task3:

# Code for task3

Space for task context saving allocated here


14/40

COMP200 14

Kernel Structure Summary

A Multitasking kernel consists of

Setup code

Runs once at the start.

Handler

Runs on every exception.

Dispatcher Called by handler on completion of timeslice.

Tasks Run when loaded by the dispatcher.


15/40

COMP200 15

Tasks

Code

Data

Registers

Processor status

Program counter Control registers

Stack

Stack pointer


16/40

COMP200 16

Task stacks

If we wish to have our tasks using stacks, then we must setupa separate stack for each task.

If we do not have separate stacks, then tasks might interferewith each other.

To setup a stack we must

Allocate some memory (probably using a .space directive)

Set the stack pointer for the task to the address of the end of thatmemory.

How much memory should we allocate?

The amount has implications for the number of nested subroutine

calls we can make. Just make sure there is enough.


17/40

COMP200 17

.equ directives

Allow us to define constants

Much like #define in C.

If we want to change the value then we only have tochange it in one place.

e.g.

.equ left_ssd_addr, 0x73002

sw $4, left_ssd_addr($0)


18/40

COMP200 18

.text, .data, and .bss

These allow us to separate the bits of ourprogram into segments

text segment Instructions

data segment Data with a specified initial value

bss segment Uninitialised data

Any .word directives in the bss segment cannot have avalue specified.


19/40

COMP200 19

.space

Allows us to allocate a certain amount of space inmemory for a data structure.

This saves us having to use .word repeatedly. Because no initial values are specified this can only

be used inside the bss segment.

e.g. reserve 18 words of space

task1_pcb:

.space 18


20/40

COMP200 20

Task stacks example

# Stack for task 1

.space 100

task1_stack:

# Stack for task 2

.space 100

task2_stack:

# Stack for task 3

.space 100

task3_stack:

For example, allocating three stacks of size 100 words:


21/40

COMP200 21

The Handler

Interrupt Handler

Use timer to generate regular (fast) interrupts

Timer is unavailable to tasks

Need to check interrupt is from timer

Every time_slice interrupts invoke dispatcher


22/40

COMP200 22

Handler Code

handler:

# Get the exception status register

movsg $13, $estat

# Check for any other exceptions than# the one we want (IRQ2)

andi $13, $13, 0xffb0

# If no other exceptions have occurred then

# we branch to our handler.

beqz $13, handle_interrupt

# Otherwise we must jump to the old# exception handler.

lw $13, old_vector($0)

jr $13

handle_interrupt:# Handle our timer interrupt


23/40

COMP200 23

Register $13

In our handler we are going to need one generalpurpose register very early on.

We need to get the $estat register so we can checkthe cause of the exception.

But we want to maintain the contents of theregisters so we dont affect our tasks.

The WRAMP processor provides for this byautomatically saving $13 on exception.

$13 is copied to the special register known as$ers (Exception Register Save).

When an rfe instruction is executed then $ersis copied back to $13.


24/40

COMP200 24

What does this mean for us?

For the programs we have been writing so far, we haventbeen worrying about whether registers are saved or not noproblem.

For our multitasking kernel, we must be careful when savingand restoring context.

Since $13 is already saved we can freely use it for the

handler and dispatcher, but we must save the value in $ersas part of the task context.

When we restore context, we must restore the appropriate$13 value from the saved context into $ers, so it will be

restored correctly when we return from exception.


25/40

COMP200 25

In terms of our code

The code in our handle_interrupt routine canonly safely use $13.

Remember we need to decrement the timeslicecounter, and maybe jump to the dispatcher.

Our dispatcher can use $13 as a base

address for the memory to save task context.

Other registers can be used once their value

has been saved.


26/40

COMP200 26

The Dispatcher

Roles of the Dispatcher

Save the context of the current task.

Determine which task should run next.

Load the next tasks context.

Continue executing with this next task.


27/40

COMP200 27

Saving Context

When we take a task off the CPU we need toremember where we were up to.

This involves saving some things to memory: All the general purpose registers (including $sp,

and $ra)

The exception address register ($ear) The CPU control register ($cctrl)

The space in memory that we save these to

is known as a Process Control Block (PCB). Each task must have its own PCB.


28/40

COMP200 28

Saving Context (cont)

We must be very careful in our dispatcher tomake sure that we dont lose the contents of

any registers before we save them. Also when we are loading context, we must

ensure that we dont change the contents of

any registers after we have restored them.


29/40

COMP200 29

Process Control Block

$1

$2

$3

$5

$4

$6

$7

$8$9

$10

$12

$11

$13

$ra$sp

$ear

$cctrl

task1_pcb:

.space 17


30/40

COMP200 30

Managing Tasks

The Dispatcher must know which task it iscurrently working on.

It must also be able to figure out which one towork on next.

It must be able to find the PCBs for eachtask so it can save and restore context.


31/40

COMP200 31

PCB version 2

$1

$2$3

$5

$4

$6

$7

$8$9

$10

$12

$11

$13

$ra

$sp

$ear

$cctrl

link

.equ pcb_link, 0

.equ pcb_reg1, 1

.equ pcb_reg2, 2

.equ pcb_reg3, 3

.equ pcb_ra, 15

.equ pcb_ear, 16

.equ pcb_cctrl, 17

.bss

task1_pcb:

.space 18

task2_pcb:

.space 18task3_pcb:

.space 18


32/40

COMP200 32

PCB linked list

$1

$2$3

$5

$4

$6

$7

$8$9

$10

$12

$11

$13

$ra

$sp

$ear

$cctrl

link

$1

$2$3

$5

$4

$6

$7

$8$9

$10

$12

$11

$13

$ra

$sp

$ear

$cctrl

link

$1

$2$3

$5

$4

$6

$7

$8$9

$10

$12

$11

$13

$ra

$sp

$ear

$cctrl

link

Task 1 PCB Task 3 PCBTask 2 PCB


33/40

COMP200 33

Setting up the tasks

Before we can get our system going we needto setup some fields in each of our PCBs.

The link field Must be set to point to the next PCB in the list.

The stack pointer field

Must be set to the bottom of the stack for that task

The $ear field

Must be set to the starting address of the task code

The $cctrl field See the next slide


34/40

COMP200 34

Setting up the $cctrl field

We want to unmask the timer interrupt (IRQ2).

We want to disable interrupts globally for now.

We want interrupts to become enabled when weexecute an rfe.

We want to ensure that we stay in kernel mode.

31 KU

OKU

IE

OIE

Undefined (set to zero) 0 0 0 0 0 0 01 1 1 0 1$cctrl

IRQ2

0x0000004d


35/40

COMP200 35

PCB setup code

# Unmask IRQ2,KU=1,OKU=1,IE=0,OIE=1

addi $5, $0, 0x4d

movgs $cctrl, $5

# Setup the pcb for task 1

la $1, task1_pcb

# Setup the link field

la $2, task2_pcb

sw $2, pcb_link($1)

# Setup the stack pointer

la $2, task1_stack

sw $2, pcb_sp($1)

# Setup the $ear field

la $2, task1_codesw $2, pcb_ear($1)

# Setup the $cctrl field

sw $5, pcb_cctrl($1)

We do thisfor each task


36/40

COMP200 36

Current task pointer

We need to maintain a pointer to the PCB of thecurrent task.

This will be initialised to the address of the PCB fortask 1.

When we switch task in the dispatcher this pointerwill be changed to the link field in the current PCB.

# Setup the first task

la $1, task1_pcb

sw $1, current_task($0)

.bss

current_task:

.word


37/40

COMP200 37

Dispatcher saving context

dispatcher:

# Get the base address of the current PCB

lw $13, current_task($0)

# Save the registers

sw $1, pcb_reg1($13)

sw $2, pcb_reg2($13)

# $1 is saved now so we can use it

# Get the old value of $13

movsg $1, $ers

# and save it to the pcbsw $1, pcb_reg13($13)

# Save $ear

movsg $1, $ear

sw $1, pcb_ear($13)

# Save $cctrlmovsg $1, $cctrl

sw $1, pcb_cctrl($13)


38/40

COMP200 38

Dispatcher switching task

# Get the contents of the link field of the current PCB

lw $13, pcb_link($13)

# Set that as our new task

sw $13, current_task($0)

$1

$2

$3

$5

$4

$6$7

$8

$9

link

$1

$2

$3

$5

$4

$6$7

$8

$9

link

current_task


39/40

COMP200 39

Dispatcher restoring context

# Get the PCB value for $13 back into $ers

lw $1, pcb_reg13($13)

movgs $ers, $1

# Restore $ear

lw $1, pcb_ear($13)

movgs $ear, $1

# Restore $cctrl

lw $1, pcb_cctrl($13)

movgs $cctrl, $1

# Restore the other registers

lw $1, pcb_reg1($13)

lw $2, pcb_reg2($13)

# Return to the new task

rfe


40/40

COMP200 40

Summary

The Handler and Dispatcher work together toprovide task switching

They must be carefully coded to save andrestore tasks exactly

The setup code provides PCBs for theDispatcher to use.

The Task Queue is formed using links in the

PCBs. Try it yourself in the exercise

10 Multitasking

Documents

Transcript of 10 Multitasking