KERNEL IMPLEMENTATION OF MONITORS FOR ERIKA

1. KERNEL IMPLEMENTATION OF MONITORS FOR ERIKA (MS Final Examination) by Sathish Kumar R. Yenna Kernel Implementation of Monitors for E.R.I.K.A.

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

3. Functional View ERIKA kernel is able to • Handle threads • Handle synchronization • Handle interrupts Kernel Implementation of Monitors for E.R.I.K.A.

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

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

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

7. ERIKA Architecture Figure 1 : Layers of ERIKA Kernel Implementation of Monitors for E.R.I.K.A.

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

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

10. Figure 2: Thread Transition Diagram Kernel Implementation of Monitors for E.R.I.K.A.

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

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. Kernel Implementation of Monitors for E.R.I.K.A.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

27. Figure 8: Typical stack configuration Kernel Implementation of Monitors for E.R.I.K.A.

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

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

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

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

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

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

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

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

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

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 */ . . . . . . } Kernel Implementation of Monitors for E.R.I.K.A.

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

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

40. Acknowledgements • Dr. Mitch Neilsen (Major Professor) • Dr. Masaaki Mizuno • Dr. Gurdip Singh Kernel Implementation of Monitors for E.R.I.K.A.

41. Questions & Comments Kernel Implementation of Monitors for E.R.I.K.A.