Glossary term

Non-Preemptive Section

Engineering definition of non-preemptive section covering disabled preemption, interrupt masking, critical-section timing, deadline risk and validation evidence.

Branch: Computer Engineering
Glossary type: phenomenon
Content: Glossary term
Updated: Jun 26, 2026
Revision: v1.0.0 · reviewed

Definition

phenomenon

A non-preemptive section is a region of execution during which the scheduler, interrupts or specific higher-priority work cannot preempt the currently running code.

Non-preemptive sections appear in real-time kernels, microcontroller firmware, device drivers, flash programming, logging paths, critical sections, scheduler locks and interrupt-masked regions. They matter because they create bounded or unbounded response delay for urgent work. A useful analysis states the protected code boundary, preemption or interrupt mask, maximum duration, affected tasks, deadline consequence, safe-state behavior and validation evidence.

A non-preemptive section is a region of execution during which the scheduler, interrupts or specific higher-priority work cannot preempt the currently running code. It can be intentional and necessary, but it must be bounded when deadlines, safe states or fault responses depend on fast reaction.

Non-preemptive sections appear in real-time kernels, embedded firmware, device drivers, flash programming, logging paths, scheduler locks, interrupt-masked regions and shared critical sections. A short section can protect consistency. A long or unmeasured section can create deadline misses even when average CPU utilization is low.

Timing Boundary

Let the start of a non-preemptive section be:

T_{np,start}

and the point where preemption or interrupt response is restored be:

T_{np,end}

The non-preemptive duration is:

T_{np}=T_{np,end}-T_{np,start}

The maximum observed or bounded value is:

T_{np,max}

The boundary should state what is disabled: all interrupts, selected interrupt priorities, task preemption, scheduler switching, migration, cancellation, lock handoff or only a local critical section.

Deadline Screen

If an urgent event requires response within:

D_e

and the rest of the response path after the section is:

T_{response,rest}

then a first screen is:

T_{np,max}+T_{response,rest}\leq D_e

The margin is:

M_D=D_e-(T_{np,max}+T_{response,rest})

The screen fails when:

M_D<0

This is why a driver that disables interrupts for a few milliseconds can break a 1 ms control loop even if the driver is rarely called.

Blocking Term

In fixed-priority analysis, a non-preemptive lower-priority section can become a blocking term:

B_i=\max(T_{np,lp})

where T_np,lp is the set of lower-priority non-preemptive sections that can delay task:

\tau_i

The bound must be linked to code and hardware state. A comment saying “short critical section” is not release evidence.

Worked Example

A protection task must respond within:

D_e=900\ \mu\text{s}

The rest of the response path after scheduling and ISR entry is:

T_{response,rest}=310\ \mu\text{s}

A logging driver disables interrupts for:

T_{np,max}=720\ \mu\text{s}

The response screen is:

T_{np,max}+T_{response,rest}=720+310=1030\ \mu\text{s}

The margin is:

M_D=900-1030=-130\ \mu\text{s}

The design fails. If the driver is split so the maximum interrupt-disabled region becomes:

T_{np,new}=260\ \mu\text{s}

then:

T_{screen,new}=260+310=570\ \mu\text{s}

and:

M_{D,new}=900-570=330\ \mu\text{s}

The timing screen now passes, assuming the new bound is measured under the same hardware and workload conditions.

Design Controls

Mitigations include moving I/O outside the protected region, splitting long critical sections, using DMA completion instead of polling, buffering diagnostics, deferring slow formatting, avoiding flash writes in urgent paths, using lock-free snapshots, reducing interrupt masking scope and using priority-aware synchronization protocols.

The strongest design is often not “make the processor faster.” It is removing the need to block urgent work while slow or variable operations complete.

Validation Evidence

Useful evidence includes trace markers around disabled-preemption regions, interrupt mask duration logs, maximum observed duration, source file and function, call frequency, hardware state, compiler settings, interrupt load, bus activity, flash wait state, cache state, p99 and maximum response delay and regression thresholds.

Validation should force the worst credible conditions: flash erase/program, logging burst, communication storm, DMA contention, high-priority interrupts, task overload, fault recovery and brown-out or reset paths. A quiet bench trace can understate the maximum section length.

Relationship To Neighbor Terms

Preemption latency is the delay from ready to running. A non-preemptive section is one cause of that delay. Interrupt latency is the delay from interrupt request to ISR response; interrupt-masked sections directly increase it. Priority inversion can include blocking on a lower-priority critical section. Lock contention measures waiting on shared serialization, while a non-preemptive section is specifically about disabling preemption or interrupt response.

WCET bounds execution after work runs. Non-preemptive sections can prevent urgent work from starting, so both belong in deadline analysis.

Common Mistakes

The most common mistake is measuring only average section duration. Another is assuming a critical section is safe because it protects data correctly. A third is using a mutex or scheduler lock around I/O, logging, memory allocation or flash writes. A fourth is testing with low interrupt and bus load, then relying on that result for overload or fault conditions.

A strong non-preemptive-section review states the code boundary, what is disabled, maximum duration, affected deadlines, mitigation and validation evidence.

REF

Disciplines