The latest development version of this page may be more current than this released 1.14.1 version.
CONFIG_NUM_METAIRQ_PRIORITIES

Number of very-high priority ‘preemptor’ threads

Type: int

Help

This defines a set of priorities at the (numerically) lowest end of the range which have “meta-irq” behavior. Runnable threads at these priorities will always be scheduled before threads at lower priorities, EVEN IF those threads are otherwise cooperative and/or have taken a scheduler lock. Making such a thread runnable in any way thus has the effect of “interrupting” the current task and running the meta-irq thread synchronously, like an exception or system call. The intent is to use these priorities to implement “interrupt bottom half” or “tasklet” behavior, allowing driver subsystems to return from interrupt context but be guaranteed that user code will not be executed (on the current CPU) until the remaining work is finished. As this breaks the “promise” of non-preemptibility granted by the current API for cooperative threads, this tool probably shouldn’t be used from application code.

Defaults

  • 0

Kconfig definition

At kernel/Kconfig:99

Included via Kconfig:10Kconfig.zephyr:31

Menu path: (top menu) → General Kernel Options

config NUM_METAIRQ_PRIORITIES
    int
    prompt "Number of very-high priority 'preemptor' threads"
    default 0
    help
      This defines a set of priorities at the (numerically) lowest
      end of the range which have "meta-irq" behavior.  Runnable
      threads at these priorities will always be scheduled before
      threads at lower priorities, EVEN IF those threads are
      otherwise cooperative and/or have taken a scheduler lock.
      Making such a thread runnable in any way thus has the effect
      of "interrupting" the current task and running the meta-irq
      thread synchronously, like an exception or system call.  The
      intent is to use these priorities to implement "interrupt
      bottom half" or "tasklet" behavior, allowing driver
      subsystems to return from interrupt context but be guaranteed
      that user code will not be executed (on the current CPU)
      until the remaining work is finished.  As this breaks the
      "promise" of non-preemptibility granted by the current API
      for cooperative threads, this tool probably shouldn't be used
      from application code.

(Definitions include propagated dependencies, including from if’s and menus.)