Personal tools

Difference between revisions of "Non-blocking Algorithms in Real-Time Operating Systems"

From iis-projects

Jump to: navigation, search
Line 4: Line 4:
[[Category:Computer Architecture]]
[[Category:Computer Architecture]]
[[Category:SW/HW Predictability and Security]]
[[Category:SW/HW Predictability and Security]]
[[Category:HW/SW Safety and Security]]
[[Category:Real-Time Embedded Systems]]
[[Category:Real-Time Embedded Systems]]

Revision as of 18:38, 23 November 2021


Status: Available


Interrupt latency and jitter is an important criterion for real-time schedulability. There are various ways to keep interrupt latency low. On the hardware-level, you can make sure that they can quickly propagate to the processor by moving parts that are slow such as the handshaking into hardware and provide features such as efficient interrupt nesting to allow high priority interrupts to get the highest attention. On the software-level you try to keep interrupt handling routines and critical sections as short as possible. In fact, the maximum interrupt latency (the worst-case) is largely determined by the method the OS uses for interrupt handling. For example, you usually disable interrupts to protect critical sections. This is necessary, because the interrupt could cause the interrupt handler or another task that might get scheduled to modify the same data structure protected by the critical section. Effectively, the critical section extends the worst-case interrupt latency by the number of cycles it takes to execute said piece of code. Non-blocking algorithms [1] [2] [3] do away with critical sections and instead use atomic read-modify-write primitives directly. This consequently reduces the worst-case interrupt latency.


The goal of this project is to look at data structures and task communication primitives used in FreeRTOS [4] [5], an open-source real-time operating system (RTOS) used by Amazon, and determine how they use critical sections. Turn these algorithms into non-blocking versions.

We have some algorithms such as a non-blocking queue already available which can serve as a starting point. As development platform ControlPULP, a version of PULP [6] [7] [8] compromising a single RISC-V controller core and eigh RISC-V accelerator cores extended to support real-time applications, can be used. Programs can be run either on an FPGA implementation thereof or in RTL simulations.

Measure the performance impact, interrupt latency and jitter.


  • 20% Literature / architecture review
  • 60% Low-level C programming
  • 20% Evaluation


  • Strong interest in computer architecture
  • Experience with low-level programming in C
  • Experience with Operating Systems


[1] Non-blocking Algorithms

[2] On the nature of progress

[3] The Art of Multiprocessor Programming

[4] FreeRTOS

[5] FreeRTOS for PULP based systems (GitHub repository)

[6] Energy-Efficient Near-Threshold Parallel Computing: The PULPv2 Cluster

[7] Mr.Wolf: An Energy-Precision Scalable Parallel Ultra Low Power SoC for IoT Edge Processing

[8] PULP (GitHub repository)