Description of refined aux task inheritance.wip-aux-tasks

1 files changed, 14 insertions, 5 deletions

diff --git a/litmus/Kconfig b/litmus/Kconfig
index c5dbc4a176ae..260b3af071c2 100644
--- a/litmus/Kconfig
+++ b/litmus/Kconfig
@@ -41,11 +41,12 @@ config REALTIME_AUX_TASKS
         help
                 Adds a system call that forces all non-real-time threads in a process
                 to become auxillary real-time tasks. These tasks inherit the priority of
-                the highest-prio *BLOCKED* real-time task (non-auxillary) in the process.
-                This allows the integration of COTS code that has background helper threads
-                used primarily for message passing and synchronization. If these
-                background threads are NOT real-time scheduled, then unbounded priority
-                inversions may occur if a real-time task blocks on a non-real-time thread.
+                the highest-prio *BLOCKED* (but NOT blocked on a Litmus lock) real-time
+                task (non-auxillary) in the process. This allows the integration of COTS
+                code that has background helper threads used primarily for message passing
+                and synchronization. If these background threads are NOT real-time scheduled,
+                then unbounded priority inversions may occur if a real-time task blocks on
+                a non-real-time thread.
 
                 Beware of the following pitfalls:
                   1) Auxillary threads should not be CPU intensive. They should mostly
@@ -65,6 +66,14 @@ config REALTIME_AUX_TASKS
                 work.). Futher, auxillary tasks without an inherited priority are
                 _always_ scheduled with a priority less than any normal real-time task!!
 
+                NOTE: Aux tasks do not _directly_ inherit a priority from rt tasks that
+                are blocked on Litmus locks. Aux task should be COTS code that know nothing
+                of Litmus, so they won't hold Litmus locks. Nothing the aux task can do can
+                _directly_ unblock the rt task blocked on a Litmus lock. However, the lock
+                holder that blocks the rt task CAN block on I/O and contribute its priority
+                to the aux tasks. Aux tasks may still _indirectly_ inherit the priority of
+                the blocked rt task via the lock holder.
+
 endmenu
 
 menu "Real-Time Synchronization"