Page History

= Critical Section Monitor

Types and Effects of Critical Sections

A critical section is a short sequence of code where exclusive execution is assured by globally disabling other activities while that code sequence executes. When we discuss _critical section_s here we really refer to one of two mechanisms:

...

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 RemovedImage Added}|elsewhere. 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.

...

    CONFIG_SCHED_CRITMONITOR=y

Platform-Specific Timers

When the Critical Section Monitor is enabled, the OS will expect platform-specific logic to export two interfaces to support the timing:

...

The second interface simple converts an elapsed time into well known units for presentation by the ProcFS file system.

Simple ARMv7-M Platform-Specific Timers

ARMv7-M platforms that support the Data Watchpoint and Trace (DWT) Unit support a very simply implementation of these timers using the DWT_CYCNT register:

...

    #ifdef CONFIG_SCHED_CRITMONITOR
      putreg32(0xc5acce55, ITM_LAR);
      modifyreg32(DWT_CTRL, 0, DWT_CTRL_CYCCNTENA_MASK);
    #endif

Per Thread and Global Critical Sections

In NuttX critical sections are controlled on a per-task basis. For example, consider the following code sequence:

...

However, if Task B that is resumed is also within a critical section, then the critical section will be extended even longer! This is why the global time that the critical section in place may be longer than any time that an individual thread holds the critical section.

ProcFS

The OS reports these maximum times via the ProcFS file system, typically mounted at /proc:

...

These statistics are cleared each time that the pseudo-file is read so that the reported values are the maximum since the last time that the ProcFS pseudo file was read.

apps/system/critmon

Also available is a application daemon at apps/sysem/critmon. This daemon periodically reads the ProcFS files described above and dumps the output to stdout. This daemon is enabled with:

...

    nsh> critmon_stop
    Csection Monitor: Stopping: 3
    Csection Monitor: Stopped: 3

IRQ Monitor and Worst Case Response Time

The IRQ Monitor is additional OS instrumentation. A full discusssion of the IRQ Monitor is beyond the scope of this Wiki Page. Suffice it to say:

...

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

What can you do?

What can you do if the timing data indicates that you cannot meet your deadline? You have these options:

...