Page History

...

The use of either mechanism will always harm real-time performance.
The effects of critical sections on real-time performance is discussed http://www.nuttx.org/doku.php?id=wiki:nxinternal:disable_latency^{Image Removed}|elsewherein Effects of Disabling Interrupts or Pre-Emption on Response Latency. The end result is that a certain amount of jitter is added to the real-time response.

...

NOTE: This discussion applies to Normal interrupt processing. Most of this discussion does not apply to High Performance, Zero Latency Interrupts. Those interrupts are not masked in the same fashion and none of the issues address in this Wiki page apply to those interrupts. That would be topic for another Wiki page.

The Critical Section Monitor

Internal OS Hooks

The Critical Section Monitor

...

In order to measure the time that tasks hold critical sections, the OS supports a Critical Section Monitor. This is internal instrumentation that records the time that a task holds a critical section. It also records the amount of time that interrupts are disabled globally. The Critical Section Monitor then retains the maximum time that the critical section is in place, both per-task and globally.

...

From this information we can calculate the worst case response time from interrupt request until a task runs that can process the the interrupt. That worst cast response time, T~T_resp~, is given by:

• T~T_resp1~ = T~T_crit~ + T~T_intr~ + C1T~
• T_resp2~ = T~T_intr~ + T~T_preempt~ + C2
• T~T_resp~ = MAX(T~T_resp1, T_resp2~)

Where:

• C1 and C2 are unknown, irreducible constants that reflect such things as hardware interrupt latency and context switching time,
• T~T_crit~ is the longest observed time within a critical section,
• T~T_intr~ is the time required for interrupt handler execution for the event of interest, and
• T~T_preempt~ is the longest observed time with preemption disabled.

...

1. This calculation assumes that the task of interest is the highest priority task in the system. It does not consider the possibility of the responding task being delayed due to insufficient priority.
2. This calculation does not address the case where the interfering task has both preemption disabled and holds the critical section. Certainly T~T_resp1~ is valid in this case, but T~T_resp2~ is not. There might some additional, unmeasured delay after the interrupt and before the responding task can run depending on the order in which the critical section is released and preemption is re-enabled:
   • When the task leaves the critical section, the pending interrupt will execute immediately with or without preemption enabled.
   • If preemption is enabled first, then the will be no delay after the interrupt because preemption will be enabled when the interrupt returns.
   • If the task leaves critical section first, then there will be some small delay of unknown duration after the interrupts returns and before the responding task can run because preemption will be disabled when the interrupt returns.
3. This calculation does not address concurrent interrupts. All interrupts run at the same priority and if an interrupt request occurs while within an interrupt handler, then it must pend until completion of that interrupt. So perhaps the above formula for T~T_resp1~ should instead be the following? (This assumes that hardware arbitration is such that the interrupt of interest will be deferred by no more than one interrupt). Concurrent, nested interrupts might be better supported with prioritized, nested interrupts.

• T~T_resp1~ = T~T_crit~ + T~T_intrmax~ + T~T_intr~ + C1

Where :

• T~T_intrmax~ is the longest interrupt processing time of all interrupt sources (excluding the interrupt for the event under consideration).

...

1. Use these tools to find the exact function that holds the critical section or disables preemption too long. Then optimize that function so that it releases that resource sooner. Often critical sections are established over long sequences or code when they could be re-designed to use critical sections over shorter code sequences.
2. In some cases, use of critical sections or disabling of pre-emption could replaced with a locking semaphore. The scope of the locking effect for the use of such locks is not global but is limited only to tasks that share the same resource. Critical sections should correctly be used only to protect resources that are shared between tasking level logic and interrupt level logic.
3. Switch to High Performance, Zero Latency Interrupts. Those interrupts are not subject to most of the issues discussed in this Wiki Page.

...