michaelh/zephyr
1
0
Fork 0
Code Releases Activity

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

Browse source 
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 <peter.bigot@nordicsemi.no>
This commit is contained in:
Peter Bigot 2020-11-04 14:36:55 -06:00 • committed by Anas Nashif
commit c42eb823ce
1 changed files with 15 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

22
doc/reference/kernel/other/interrupts.rst
View file

@ -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.