Changes between Version 54 and Version 55 of Developer/SMP

Timestamp:

03/31/14 16:03:43 (10 years ago)

Author:

Sh

Comment:

/* Thread Restart */ Update due to recent thread life cycle changes

Developer/SMP

@@ -506 +506 @@
 
 
-The restart of threads other than self is not implemented.
+The restart of threads is 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.
+The restart of threads is implemented via post-switch thread actions.  The post-switch thread actions use the per-CPU lock and have very little overhead if no post-switch actions must be performed.  Most architectures should be updated to use an interrupt epilogue similar to the SPARC to avoid long interrupt disable times.
 
 Why execute post-switch handlers with interrupts disabled on some architectures
@@ -542 +531 @@
 interrupt contexts.
 
-This scheme could be used for all architectures.  Further discussion is
-necessary.  An alternative to post-switch handlers is currently unknown.
+This scheme could be used for all architectures.
 =  Thread Delete  =
 
@@ -1498 +1486 @@
 
 One approach to do post-switch actions could be to spin on the per-processor
-variable reflecting the executing thread.  This has at least two prob
+variable reflecting the executing thread.  This has at least two problems
+# it doesn't work if the executing thread wants to alter its own state, and
+# this spinning must be done with the scheduler lock held and interrupts disabled, this is a disaster for the interrupt latency,
+
+The proposed solution is to use an optional action handler which is active in
+case the thread execution termination matters.  In _Thread_Dispatch() we have
+already the post-switch extensions invoked after a thread switch.
+Unfortunately they execute after thread dispatching is enabled again and at
+this point the current processor may have already changed due to thread
+migration requested by an interrupt.
+
+We need a context which executes right after the thread context switch on the
+current processor, but without the per-processor lock acquired (to prevent lock
+order reversal problems and keep the interrupt latency small).  For this we
+introduce a post-switch action chain (PSAC).  Each thread will have its own
+PSAC control.  The PSAC operations like addition to, removal from and iteration
+over the ch