doc: kernel: interrupts: correct description of irq lock behavior

Contrary to the documentation giving a semaphore while an IRQ lock is held does not release the lock and give control to another thread. The release-lock behavior is observed only if the lock-holding thread sleeps. However the opportunity to reschedule will have been lost so it may be necessary to explicitly yield to allow the higher-priority thread to be serviced. Signed-off-by: Peter Bigot <[email protected]>
piotrrak · May 7, 2021 · c42eb82 · c42eb82
1 parent d83647d
commit c42eb82
Showing 1 changed file with 15 additions and 7 deletions.
diff --git a/doc/reference/kernel/other/interrupts.rst b/doc/reference/kernel/other/interrupts.rst
@@ -134,18 +134,26 @@ is running.
 
 .. important::
     The IRQ lock is thread-specific. If thread A locks out interrupts
-    then performs an operation that allows thread B to run
-    (e.g. giving a semaphore or sleeping for N milliseconds), the thread's
-    IRQ lock no longer applies once thread A is swapped out. This means
-    that interrupts can be processed while thread B is running unless
-    thread B has also locked out interrupts using its own IRQ lock.
-    (Whether interrupts can be processed while the kernel is switching
-    between two threads that are using the IRQ lock is architecture-specific.)
+    then performs an operation that puts itself to sleep (e.g. sleeping
+    for N milliseconds), the thread's IRQ lock no longer applies once
+    thread A is swapped out and the next ready thread B starts to
+    run.
+
+    This means that interrupts can be processed while thread B is
+    running unless thread B has also locked out interrupts using its own
+    IRQ lock.  (Whether interrupts can be processed while the kernel is
+    switching between two threads that are using the IRQ lock is
+    architecture-specific.)
 
     When thread A eventually becomes the current thread once again, the kernel
     re-establishes thread A's IRQ lock. This ensures thread A won't be
     interrupted until it has explicitly unlocked its IRQ lock.
 
+    If thread A does not sleep but does make a higher-priority thread B
+    ready, the IRQ lock will inhibit any preemption that would otherwise
+    occur.  Thread B will not run until the next :ref:`reschedule point
+    <scheduling_v2>` reached after releasing the IRQ lock.
+
 Alternatively, a thread may temporarily **disable** a specified IRQ
 so its associated ISR does not execute when the IRQ is signaled.
 The IRQ must be subsequently **enabled** to permit the ISR to execute.