Changes between Version 26 and Version 27 of Developer/SMP

Timestamp:

01/13/14 16:03:26 (10 years ago)

Author:

Sh

Comment:

/* Thread Restart */

Developer/SMP

@@ -403 +403 @@
 application-level threads in global resources - not the full task, only that
 ''protected'' execution - in accord with <ref name="BurnsWellings2013"/>.
-= = Task Variables  ==
+=  Task Variables  =
 
 ==  Status  ==
@@ -412 +412 @@
 of the executing thread.  For Newlib the access to the re-entrancy structure is
 now performed via ''__getreent()'',  see also ''__DYNAMIC_REENT__'' in Newlib.
-=  === Future Directions ====
+==  Future Directions  ==
 
 
@@ -418 +418 @@
  *  Fix file system environment.
  *  Fix C++ support.
-
-=== Non-Preempt Mode for Mutual Exclusion ===
-
-
-==== Status ====
+=  Non-Preempt Mode for Mutual Exclusion  =
+
+==  Status  ==
 
 
@@ -429 +427 @@
 a mode change request is issued.  The alternatives are mutexes and condition
 variables.
-
-==== Future Directions ====
+==  Future Directions  ==
 
 
@@ -437 +434 @@
  *  Fix the block device cache ''bdbuf''.
  *  Fix C++ support.
-
-=== Thread Restart ===
-
-
-=== Thread Delete ===
-
-
-=== Semaphores and Mutexes ===
+=  Thread Restart  =
+
+==  Status  ==
+
+
+The restart of threads other than self is not implemented.
+==  Future Directions  ==
+
+
+Implement the missing feature.  The difficult path is the restart of executing
+remote threads.  Executing remote threads may perform a context switch at any
+time.  This would overwrite a newly initialized thread context.  An option is a
+post-switch handler that performs a self-restart if necessary.
+
+Post-switch handlers have some disadvantages:
+
+ *  They add a function call via function pointer overhead to every invocation of ''_Thread_Dispatch()''.  Post-switch handlers have to check on every invocation if they have something to do.
+ *  Currently post-switch handlers are only used for signal management.  Some work was done to install post-switch handlers only on demand since performance measurements showed that they are indeed a problem.
+ *  Depending on the low-level interrupt support they may execute with interrupts disabled and thus increase the worst-case interrupt latency.
+ *  Dynamic add/remove of post-switch handlers is problematic since in this case some lock strategy must be used which makes ''_Thread_Dispatch()'' more complex and has an execution overhead.
+ *  Per-CPU specific post-switch handlers are an option.  They can use the per-CPU lock which must be obtained in ''_Thread_Dispatch()'' anyway.
+
+Why execute post-switch handlers with interrupts disabled on some architectures
+(e.g. ARM and PowerPC)?  The most common interrupt handling sequence looks like
+this:
+
+[wiki:File:rtems-smp-isr-1.png File:rtems-smp-isr-1.png]
+
+In this sequence it is not possible to enable interrupts around the
+''_Thread_Dispatch()'' call.  This could lead to an unlimited number of interrupt
+contexts saved on the thread stack.  To overcome this issue some architectures
+use a flag variable that indicates this particular execution environment (e.g.
+the SPARC).  Here the sequence looks like this:
+
+[wiki:File:rtems-smp-isr-2.png File:rtems-smp-isr-2.png]
+
+The ISR thread dispatch disable flag must be part of the thread context.  The
+context switch will save/restore the per-CPU ISR dispatch disable flag to/from
+the thread context.  Each thread stack must have space for at least two
+interrupt contexts.
+
+This scheme could be used for all architectures.  Further discussion is
+necessary.  An alternative to post-switch handlers is currently unknown.
+= = Thread Delete  ==
+
+=  == Semaphores and Mutexes ===