Kernel implementation of monitors for erika
Sponsored Links
This presentation is the property of its rightful owner.
1 / 41

KERNEL IMPLEMENTATION OF MONITORS FOR ERIKA PowerPoint PPT Presentation


  • 172 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

KERNEL IMPLEMENTATION OF MONITORS FOR ERIKA

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

(MS Final Examination)

by

Sathish Kumar R. Yenna

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


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

ERIKA kernel is able to

  • Handle threads

  • Handle synchronization

  • Handle interrupts

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


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

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

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

Figure 1 : Layers of ERIKA

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


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

  • 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

  • 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 Layer uses TIDs to identify threads

    – allows implementation of scheduling algorithms in a hardware independent way

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


Code Portability

  • 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

  • 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

  • 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

  • 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

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

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

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

  • 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

User Stack

Figure 7: Typical stack layout of a preempted thread.

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


Stack 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

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


Figure 8: Typical stack configuration

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


MONITORS

  • 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

  • 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

  • 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

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)

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

  • 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

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

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


    Interface for the applications

    • 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

      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

    • 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

    • 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

    • Dr. Mitch Neilsen (Major Professor)

    • Dr. Masaaki Mizuno

    • Dr. Gurdip Singh

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


    Questions & Comments

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


  • Login