Kernel implementation of monitors for erika
Download
1 / 41

KERNEL IMPLEMENTATION OF MONITORS FOR ERIKA - PowerPoint PPT Presentation


  • 211 Views
  • Uploaded on

KERNEL IMPLEMENTATION OF MONITORS FOR ERIKA. (MS Final Examination) by Sathish Kumar R. Yenna. Introduction to ERIKA. ERIKA (Embedded Real tIme Kernel Architecture) is a research project about micro-kernel architectures for embedded systems. Very structured and easy to port.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' KERNEL IMPLEMENTATION OF MONITORS FOR ERIKA' - avery


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Kernel implementation of monitors for erika

KERNEL IMPLEMENTATION OF MONITORS FOR ERIKA

(MS Final Examination)

by

Sathish Kumar R. Yenna

Kernel Implementation of Monitors for E.R.I.K.A.


Introduction to erika
Introduction to ERIKA

  • ERIKA (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

Kernel Implementation of Monitors for E.R.I.K.A.


Functional view
Functional View

ERIKA kernel is able to

  • Handle threads

  • Handle synchronization

  • Handle interrupts

Kernel Implementation of Monitors for E.R.I.K.A.


Thread handling
Thread Handling

ERIKA 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

Kernel Implementation of Monitors for E.R.I.K.A.


Thread status
Thread Status

A 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 execute

  • idle state - terminated and not in the ready queue

  • blocked state - blocked on a synchronizing condition

Kernel Implementation of Monitors for E.R.I.K.A.


Thread synchronization
Thread Synchronization

Mutexes – for mutual exclusion

CABs – Cyclical Asynchronous Buffers

Semaphores

Interrupt 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

Kernel Implementation of Monitors for E.R.I.K.A.


Erika architecture
ERIKA Architecture

Figure 1 : Layers of ERIKA

Kernel Implementation of Monitors for E.R.I.K.A.


Kernel layer
Kernel 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

Kernel Implementation of Monitors for E.R.I.K.A.


Kernel api
Kernel 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()

Kernel Implementation of Monitors for E.R.I.K.A.


Figure 2: Thread Transition Diagram

Kernel Implementation of Monitors for E.R.I.K.A.


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

Kernel Implementation of Monitors for E.R.I.K.A.


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

Kernel Implementation of Monitors for E.R.I.K.A.


Hardware abstraction layer
Hardware Abstraction Layer by a call of

  • Main objective – export the abstraction of the thread to the kernel layer

  • A thread is characterized by

    • a body

    • a context

  • Provides a clean interface for the kernel

    • Context handling

    • Interrupt handling and other utility functions

Kernel Implementation of Monitors for E.R.I.K.A.


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

Kernel Implementation of Monitors for E.R.I.K.A.


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

Kernel Implementation of Monitors for E.R.I.K.A.


Kernel Implementation of Monitors for E.R.I.K.A.


Code portability
Code Portability at higher priority with respect to the running thread A.

  • The division of the Kernel into two layers

  • A standard interface provided by the HAL

    eases the porting to different architectures

Kernel Implementation of Monitors for E.R.I.K.A.


Erika hals
ERIKA HALs at higher priority with respect to the running thread A.

  • 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)

Kernel Implementation of Monitors for E.R.I.K.A.


Modular architecture
Modular Architecture at higher priority with respect to the running thread A.

  • 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…)

Kernel Implementation of Monitors for E.R.I.K.A.


System startup
System Startup at higher priority with respect to the running thread A.

  • 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 ! ! !

Kernel Implementation of Monitors for E.R.I.K.A.


Dummy thread
dummy() thread at higher priority with respect to the running thread A.

  • 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>

    }

Kernel Implementation of Monitors for E.R.I.K.A.


Thread execution

Thread scheduling at higher priority with respect to the running thread A.

Thread Execution

Thread termination

SP

SP

RETI: (IP)  ((SP))

(SP)  (SP) + 2

(PSW)  ((SP))

(SP)  (SP) + 2

RET: (IP)  ((SP))

(SP)  (SP) + 2

Kernel Implementation of Monitors for E.R.I.K.A.


St10 c167 hal internals
ST10/C167 HAL Internals at higher priority with respect to the running thread A.

ERIKA provides three HALs for ST10/C167 platform

  • Mono-Stack HAL

  • Multi-Stack HAL

  • Segmented Multi-Stack HAL

Kernel Implementation of Monitors for E.R.I.K.A.


Multi stack hal for st10 c167
Multi-Stack HAL for ST10/C167 at higher priority with respect to the running thread A.

  • Each thread has a stack, a context, and a body

  • Stack and context may be shared

    Data structures initialized by the user

    iram ADDR st10_thread_body[]

    iram ADDR st10_thread_cp[]

    iram UINT16 st10_user_stack[]

Kernel Implementation of Monitors for E.R.I.K.A.


Top of the Stack at higher priority with respect to the running thread A.

User Stack

Figure 7: Typical stack layout of a preempted thread.

Kernel Implementation of Monitors for E.R.I.K.A.


Stack implementation
Stack Implementation at higher priority with respect to the running thread A.

  • 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

Kernel Implementation of Monitors for E.R.I.K.A.


Figure 8: Typical stack configuration at higher priority with respect to the running thread A.

Kernel Implementation of Monitors for E.R.I.K.A.


Monitors
MONITORS at higher priority with respect to the running thread A.

  • 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

Kernel Implementation of Monitors for E.R.I.K.A.


Condition variables
Condition Variables at higher priority with respect to the running thread A.

  • 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

Kernel Implementation of Monitors for E.R.I.K.A.


Implementation
Implementation at higher priority with respect to the running thread A.

  • 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)

Kernel Implementation of Monitors for E.R.I.K.A.


Monitor primitives
Monitor Primitives at higher priority with respect to the running thread A.

procedure enter (name: monitor index)

find descriptor for monitor name

if lock = 1  insert descriptor of executing at the end of entry queue; executing := 0

[] lock = 0 ! lock := 1

fi

call dispatcher()

end

procedure exit (name: monitor index)

find descriptor for monitor name

if 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 lock

fi

call dispatcher()

end

Kernel Implementation of Monitors for E.R.I.K.A.


procedure wait (name: monitor index; cname: condvar index) at higher priority with respect to the running thread A.

find descriptor for the condition variable cname

insert descriptor of executing at the end of the delay queue; executing := 0

call exit (name)

end

procedure signal (name: monitor index; cname: condvar index)

find descriptor for monitor name

find descriptor for condition variable cname

if delay queue not empty 

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

fi

call dispatcher()

end

Kernel Implementation of Monitors for E.R.I.K.A.


Data structures added
Data structures added at higher priority with respect to the running thread A.

  • 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;

  • Kernel Implementation of Monitors for E.R.I.K.A.


    Kernel primitives used
    Kernel Primitives used at higher priority with respect to the running thread A.

    void 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)

    Kernel Implementation of Monitors for E.R.I.K.A.


    Monitor primitives1
    Monitor Primitives at higher priority with respect to the running thread A.

    • 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

    Kernel Implementation of Monitors for E.R.I.K.A.


    Interface for the applications
    Interface for the applications at higher priority with respect to the running thread A.

    • Monitor definition

      MON mon1 = {0, NIL, NIL};

    • Condition Variable definition

      CONDVAR cond1 = {NIL, NIL};

    Kernel Implementation of Monitors for E.R.I.K.A.


    • An Example at higher priority with respect to the running thread A.

      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 */

      . . .

      . . .

      }

    Kernel Implementation of Monitors for E.R.I.K.A.


    Conclusion
    Conclusion at higher priority with respect to the running thread A.

    • Basic 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

    Kernel Implementation of Monitors for E.R.I.K.A.


    References
    References at higher priority with respect to the running thread A.

    • 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)

    Kernel Implementation of Monitors for E.R.I.K.A.


    Acknowledgements
    Acknowledgements at higher priority with respect to the running thread A.

    • Dr. Mitch Neilsen (Major Professor)

    • Dr. Masaaki Mizuno

    • Dr. Gurdip Singh

    Kernel Implementation of Monitors for E.R.I.K.A.


    Questions comments
    Questions & Comments at higher priority with respect to the running thread A.

    Kernel Implementation of Monitors for E.R.I.K.A.


    ad