From c42eb823ce5484e76f6268253c6606be3b30b777 Mon Sep 17 00:00:00 2001 From: Peter Bigot Date: Wed, 4 Nov 2020 14:36:55 -0600 Subject: [PATCH] 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 --- doc/reference/kernel/other/interrupts.rst | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/doc/reference/kernel/other/interrupts.rst b/doc/reference/kernel/other/interrupts.rst index 5e4c4fec4eb..2624501b05a 100644 --- 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 + ` 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.