Skip to content

Inconsistent enabling/disabling of interrupts #11

Description

@mavaneerden

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions