Sometimes, interrupts are disabled and enabled inconsistently. For example, here interrupts are disabled when checking the next thread:
|
__disable_interrupt(); |
|
// check the ready queue for the last time |
|
if(!__next_thread()){ |
|
__mcu_sleep(); |
|
__enable_interrupt(); |
|
} |
(also in this example, if there IS a next thread, interrupts are not re-enabled)
But then, interrupts are NOT disabled when checking the next thread here:
|
case SCHED_SELECT: |
|
// the scheduler selects the highest priority task right |
|
// after it has finished the execution of a single task |
|
_thread = __next_thread(); |
|
_sched_state = SCHED_BUSY; |
I don't really understand why interrupts are not disabled in the second case. In both cases, an ISR could interrupt the priority calculation at the wrong time by signalling a thread, leading to inconsistent readyLevel and readyTable values.
Sometimes, interrupts are disabled and enabled inconsistently. For example, here interrupts are disabled when checking the next thread:
InK/Kernel/scheduler/scheduler.c
Lines 188 to 193 in 2a95405
(also in this example, if there IS a next thread, interrupts are not re-enabled)
But then, interrupts are NOT disabled when checking the next thread here:
InK/Kernel/scheduler/scheduler.c
Lines 173 to 177 in 2a95405
I don't really understand why interrupts are not disabled in the second case. In both cases, an ISR could interrupt the priority calculation at the wrong time by signalling a thread, leading to inconsistent
readyLevelandreadyTablevalues.