KERNEL IMPLEMENTATION OF MONITORS FOR ERIKA

4th December 2003 Kernel Implementation of Monitors for E.R.I.K.A.

1

KERNEL IMPLEMENTATION KERNEL IMPLEMENTATION OF MONITORS FOR ERIKAOF MONITORS FOR ERIKA

(MS Final Examination)

by

Sathish Kumar R. Yenna


2

Introduction to ERIKAIntroduction to ERIKAERIKA (Embedded Real tIme Kernel

Architecture) is a research project about micro-kernel architectures for embedded systems.

Very structured and easy to port.Currently, it has kernels for

– ST10/C167 architecture– ARM7TDMI architecture


3

Functional ViewFunctional View

ERIKA kernel is able to Handle threads Handle synchronization Handle interrupts


4

Thread HandlingThread HandlingERIKA provides only the basic features required for

thread handling - scheduling, activation and context switching

Each thread owns a set of attributes TID – Thread IDentifier Body Function Priority User Stack (Multi-Stack HAL) Register Bank Status Word


5

Thread StatusThread StatusA thread can be in one of the following four states:

stacked state - started execution and its frame is on stack (running or preempted)

ready state - activated and ready to executeidle state - terminated and not in the ready

queueblocked state - blocked on a synchronizing

condition


6

Thread SynchronizationThread Synchronization Mutexes – for mutual exclusion CABs – Cyclical Asynchronous Buffers Semaphores

Interrupt HandlingInterrupt Handling It can be configured to handle interrupts in a clean

way Provides an interface that allows linking a handler

written by the user to an interrupt vector


7

ERIKA ArchitectureERIKA Architecture

Application Layer (user tasks)

Kernel Layer (hardware independent routines)

Hardware Abstraction Layer (hardware dependent routines)

Figure 1 : Layers of ERIKA


8

Kernel LayerKernel Layer Exports system primitives to the application Written in standard C language Independent from the underlying architecture

Services provided by the Kernel Layer Queue Handling – queue structures to keep track of the thread

status

Scheduling – primitives to schedule threads

User interface – data types, data structures and primitives for the application


9

Kernel APIKernel API Thread Management: thread_make_ready()

thread_activate() sys_scheduler() thread_end_instance()

Thread Management in Interrupt Handlers: IRQ_make_ready() IRQ_end_instance() set_handler()

Shared Memory Management: mutex_lock() mutex_unlock()

Utility Functions: sys_gettime() sys_panic() sys_reboot() sys_idle()


10

Figure 2: Thread Transition Diagram


11

Figure 3: Context changes due to the activation of thread B that has higher priority with respect to the running thread A


12

Figure 4: Context switches due to the activation of thread B by a call of thread_make_ready() by a lower priority thread A.


13

Hardware Abstraction LayerHardware Abstraction LayerMain objective – export the abstraction of

the thread to the kernel layerA thread is characterized by

– a body – a context

Provides a clean interface for the kernel– Context handling– Interrupt handling and other utility functions


14

Figure 5: Interaction between the kernel layer primitives and the HAL functions for context handling


15

Figure 6: Context change due to the activation of a thread B at higher priority with respect to the running thread A.


16

Kernel Layer uses TIDs to identify threads

– allows implementation of scheduling algorithms in a hardware independent way


17

Code PortabilityCode Portability

The division of the Kernel into two layersA standard interface provided by the HAL

eases the porting to different architectures


18

ERIKA HALsERIKA HALs

Mono-Stack HAL– All the threads and interrupts share the same stack– Preempted thread can not execute again before all the

threads have finished their instances.– Blocking primitives are not allowed

Multi-Stack HAL– Each thread can have its own stack– Blocking primitives are allowed (ex. semaphores)


19

Modular ArchitectureModular Architecture Each part of the system can be thought as a module that

can be included or not in the final image file This helps the process of optimizing memory foot print

Users can choose the following options at compile time– Hardware architecture– HAL (mono-stack or multi-stack)– Scheduling algorithm– External modules (semaphores, mailboxes etc…)


20

System StartupSystem Startup

main function: main(void) {<hardware initialization stuff>st10_start(first thread ID);return 0;}

st10_start() function: _st10_start PROC NEAR <clean the system stack –

empty><push PSW><push #_dummy><RETI> ; Now the

game starts ! ! !


21

dummy() threaddummy() thread– startup point of the application– does not have a TID– never ends– lowest priority thread in the system– always active and hence never activated

void dummy() {<system initialization><thread activation><scheduling><idle loop>

}


22

Thread ExecutionThread Execution

Thread scheduling

#ENDINSTANCE

PSW #800h

IP (my_thread( ))SP

RETI: (IP) ((SP))

(SP) (SP) + 2

(PSW) ((SP))

(SP) (SP) + 2

#ENDINSTANCESP

RET: (IP) ((SP))

(SP) (SP) + 2

Thread termination


23

ST10/C167 HAL InternalsST10/C167 HAL InternalsERIKA provides three HALs for ST10/C167 platform

– Mono-Stack HAL– Multi-Stack HAL– Segmented Multi-Stack HAL

Mono-Stack Multi-StackSegmented Multi-Stack

Speed Fastest Fast Slow

Single Stack Yes No No

Blocking Primitives Allowed No Yes Yes

Memory Model Tiny Tiny Large

Functions store return values into user stack

No No Yes


24

Multi-Stack HAL for ST10/C167Multi-Stack HAL for ST10/C167

– Each thread has a stack, a context, and a body– Stack and context may be shared

Data structures initialized by the useriram ADDR st10_thread_body[]

iram ADDR st10_thread_cp[]

iram UINT16 st10_user_stack[]


25

Figure 7: Typical stack layout of a preempted thread.

Top of the Stack

User Stack


26

Stack ImplementationStack Implementation Multi-Stack HAL has to switch the user stack at each thread

change System stack is in internal memory and user stack is in

external memory System stack is used for parameter passing System stack of each thread is mapped to a different location

of the global system stack No check on stack overflow is done

Important data structures: iram UINT16 st10_thread_tos[]

iram struct_tos stack_tos[]

iram WORD st10_active_tos


27

Figure 8: Typical stack configuration


28

MONITORSMONITORS Provide a structured approach for process synchronization Can be implemented as efficient as semaphores Data abstraction mechanism: They encapsulate the

representation of the abstract resources and provide a set of operations that are the only means by which they are manipulated

Mutual exclusion is provided by ensuring that the execution of procedures in the same monitor is not overlapped

Condition synchronization in monitors is provided by a low-level mechanism called condition variables


29

Condition VariablesCondition Variables

Declaration

var c:cond Delay a process

wait(c) Wake up a process

signal(c)

Programmer has to take care of inserting wait and signal operations at appropriate locations to avoid permanent blocking of processes


30

ImplementationImplementation Monitors can be implemented in two ways

– Using semaphores– Using kernel primitives

Kernel requirements– Each process should have a descriptor– Descriptors that are to execute should be linked together on a

ready queue Primitives to be added

– Monitor entry– Monitor exit– Each of the operation on the condition variables (wait and signal)


31

Monitor PrimitivesMonitor Primitivesprocedure enter (name: monitor index)

find descriptor for monitor nameif lock = 1 insert descriptor of executing at the end of entry queue; executing := 0[] lock = 0 ! lock := 1ficall dispatcher()

end

procedure exit (name: monitor index)find descriptor for monitor nameif entry queue not empty

move process descriptor from front of the entry queue to rear of ready list.

[] entry queue empty lock := 0 #clear the lockficall dispatcher()

end


32

procedure wait (name: monitor index; cname: condvar index)find descriptor for the condition variable cnameinsert descriptor of executing at the end of the delay queue; executing := 0call exit (name)

end

procedure signal (name: monitor index; cname: condvar index)find descriptor for monitor namefind descriptor for condition variable cnameif delay queue not empty

move process descriptor from front of delay queue to rear of entry queue.

ficall dispatcher()

end


33

Data structures addedData structures added Monitor Descriptor

Lock Queue of waiting processes

typedef struct {UINT8 lock;TID first;TID last;

} MON;

Condition Variable Descriptor Queue of delayed processes

typedef struct {TID first;TID last;

} CONDVAR;


34

Kernel Primitives usedKernel Primitives usedvoid hal_begin_primitive(void)void hal_end_primitive(void)TID rq_queryfirst(void)TID stk_queryfirst(void)void stk_getfirst(void)void rq_insert(TID t)void hal_stkchange(TID t)TID rq2stk_exchange(void)void hal_ready2stacked(TID t)void sys_scheduler(void)


35

Monitor PrimitivesMonitor Primitives void mon_enter(MON *mon)

Lock and enter the monitor

void mon_exit(MON *mon)Unlock and exit the monitor

void mon_wait(MON *mon, CONDVAR *cond)Wait on the condition variable

void mon_signal(MON *mon, CONDVAR *cond)Signal the process at the front of the cond’s delay queue

void mon_signalall(MON *mon, CONDVAR *cond)Signal all the processes in the cond’s delay queue


36

Interface for the applicationsInterface for the applications

Monitor definition

MON mon1 = {0, NIL, NIL};

Condition Variable definition

CONDVAR cond1 = {NIL, NIL};


37

An Example

MON mon = {0, NIL, NIL};CONDVAR oktoread = {NIL, NIL};void thread_example() {. . .. . ./* The task enters a critical section/monitor */mon_enter(&mon);if (nw > 0)

mon_wait (&mon, &oktoread);nr = nr + 1;mon_exit (&mon);/* The task leaves the critical section/monitor */. . .. . .}


38

ConclusionConclusionBasic ERIKA does not support monitors,

which provide an efficient data abstraction mechanism

This implementation enables the users to directly declare, define and use monitors in their applications


39

ReferencesReferences ERIKA web pages : http://erika.sssup.it Paolo Gai and Alessandro Colantonio. ERIKA User Manual (draft

version). April 29, 2002 Paolo Gai. ERIKA Mono-Stack Documentation Notes. November 21,

2000 Paolo Gai. ERIKA Multi-Stack Documentation Notes. November 21,

2000 Gregory R. Andrews. Concurrent Programming – Principles and

Practice Brian W. Kernighan and Dennis M. Ritchie. The C Programming

Language SIEMENS AG. Instruction Set Manual for the C166 Family (Version

1.2, 12.97)


40

AcknowledgementsAcknowledgementsDr. Mitch Neilsen (Major Professor)Dr. Masaaki MizunoDr. Gurdip Singh


41

Questions & CommentsQuestions & Comments

KERNEL IMPLEMENTATION OF MONITORS FOR ERIKA

Documents

Transcript of KERNEL IMPLEMENTATION OF MONITORS FOR ERIKA