michaelh/zephyr
1
0
Fork 0
Code Releases Activity

kernel/arm: add comment about _is_next_thread_current

Browse source 
Normally, _is_next_thread_current() must be called with interrupts
locked, but the ARM interrupt exit code does not have to do that. Add
explanation why.

Change-Id: Id383b47a055fdd6fbd5afffa52772e92febde98f
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
This commit is contained in:
Benjamin Walsh 2016-11-14 13:48:13 -05:00 • committed by Anas Nashif
commit dfa7ca4ee5
1 changed files with 22 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

22
arch/arm/core/exc_exit.S
View file

@ -103,6 +103,28 @@ SECTION_SUBSEC_FUNC(TEXT, _HandlerModeExit, _ExcExit)
bgt _EXIT_EXC
push {lr}
/*
* _is_next_thread_current() calls _get_next_ready_thread(), which is
* supposed to be called only with interrupts locked: interrupts are _not_
* locked at this point. However, that is not a problem in this case:
*
* - Threads can only be added to the ready queue in an ISR, not removed.
* Thus, priorities with runnable thread can only be added as well.
*
* - The PendSV handler is the context that will decide which thread to
* run, not the current context.
*
* - The current decision to pend PendSV or not is started with the ready
* queue state that the currently exiting ISR updated: if that state
* changes, it can only be to add a thread as runnable, not remove one.
*
* - The only discrepancy that can happen is if another ISR preempts the
* current one and makes another thread than the current the next thread
* to run, if the current ISR did not do already that. In that case, even
* if the decision is interrupted, the current code running in the higher
* priority ISR _will_ take the correct decision to pend PendSV.
*/
blx _is_next_thread_current
#if defined(CONFIG_CPU_CORTEX_M0_M0PLUS)
pop {r1}