Preemptive multitasking - Revision history

Ebiggers at 01:57, 12 September 2013

2013-09-12T01:57:15Z

Ebiggers: arch_setup_stack(): Note called by create()

2013-09-08T15:12:10Z

arch_setup_stack(): Note called by create()

Ebiggers: Adjust link

2013-09-08T15:11:15Z

Adjust link

Ebiggers: Created page

2013-09-08T14:58:08Z

Created page

New page

Like virtually all modern operating systems, [[Embedded Xinu]] supports '''preemptive multitasking''', which makes it appear that multiple threads are executing at the same time on the same processor. Support for preemptive multitasking consists of support for multiple threads combined with a preemption mechanism.

== Multiple threads ==

Embedded Xinu supports multiple threads, but only one can execute at a time. A '''thread context''' refers to the saved state of a thread, primarily CPU registers. Embedded Xinu platforms must implement two functions to allow creating new threads and switching between threads using their thread contexts:

* <code>arch_setup_stack()</code>, which is responsible for setting up the stack of a new thread to include an initial thread context and procedure arguments. This routine is typically implemented in C.
* <code>ctxsw()</code>, which is responsible for switching between threads. More specifically, this routine must save the thread context of the current thread and restore the thread context of the new thread. This routine is always implemented in assembly language.

Since different CPU architectures use different registers and calling conventions,
the size and format of a thread context varies depending on the CPU architecture.
Note that since thread contexts are created in both <code>arch_setup_stack()</code> and <code>ctxsw()</code>, these two routines must create contexts that are compatible, at least to the extent that <code>ctxsw()</code> can either start a new thread or resume an existing thread.

See [[Preemptive_multitasking_(ARM)]] for an example.

== Preemption ==

Preemption occurs when the timer interrupt occurs and Embedded Xinu attempts to reschedule the currently executing thread, which results in a call to <code>ctxsw()</code>, described above, that may switch to a different thread context. (We say ''may'' because the code is written such that <code>ctxsw()</code> is called when the same thread is rescheduled to itself, in which case <code>ctxsw()</code> restores the saved context immediately and is a no-op.) The means of generating a timer interrupt is platform-dependent and may even differ among platforms that share the same CPU architecture. For an example, see [[BCM2835 System Timer]], which is used in the [[Raspberry Pi]], an ARM-based platform.

@@ Line 5: / Line 5: @@
 Embedded Xinu supports multiple threads, but only one can execute at a time.  A '''thread context''' refers to the saved state of a thread, primarily CPU registers.  Embedded Xinu platforms must implement two functions to allow creating new threads and switching between threads using their thread contexts:
-* <code>arch_setup_stack()</code>, which is responsible for setting up the stack of a new thread to include an initial thread context and procedure arguments.  This routine is typically implemented in C.  It is called internally by <code>create()</code>.
+* <code>arch_setup_stack()</code>, which is responsible for setting up the stack of a new thread to include an initial thread context and procedure arguments.  This routine is typically implemented in C.  It is called internally by <code>create()</code>, located in {{SourceFile|system/create.c}}.  For an example, see {{SourceFile|system/arch/mips/arch_setup_stack.c}}.
-* <code>ctxsw()</code>, which is responsible for switching between threads.  More specifically, this routine must save the thread context of the current thread and restore the thread context of the new thread.  This routine is always implemented in assembly language.
+* <code>ctxsw()</code>, which is responsible for switching between threads.  More specifically, this routine must save the thread context of the current thread and restore the thread context of the new thread.  This routine is always implemented in assembly language.  For an example, see {{SourceFile|system/arch/mips/ctxsw.S}}.
 Since different CPU architectures use different registers and calling conventions,
@@ Line 12: / Line 12: @@
 Note that since thread contexts are created in both <code>arch_setup_stack()</code> and <code>ctxsw()</code>, these two routines must create contexts that are compatible, at least to the extent that <code>ctxsw()</code> can either start a new thread or resume an existing thread.
-See [[Preemptive_multitasking_(ARM)|Preemptive multitasking (ARM)]] for an example.
+Other articles describe this in more detail for specific architectures:
 == Preemption ==
 Preemption occurs when the timer interrupt occurs and Embedded Xinu attempts to reschedule the currently executing thread, which results in a call to <code>ctxsw()</code>, described above, that may switch to a different thread context.  (We say ''may'' because the code is written such that <code>ctxsw()</code> is called when the same thread is rescheduled to itself, in which case <code>ctxsw()</code> restores the saved context immediately and is a no-op.)  The means of generating a timer interrupt is platform-dependent and may even differ among platforms that share the same CPU architecture.  For an example, see [[BCM2835 System Timer]], which is used in the [[Raspberry Pi]], an ARM-based platform.