Fast Mutex Mechanism for Priority Inversion in Real-Time OS

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current microkernel designs face performance penalties due to computationally expensive priority inheritance mechanisms, leading to potential unreliability in real-time operating systems, where priority inversion can cause high-priority tasks to be blocked by low-priority tasks holding locks, necessitating a trade-off between robustness and performance.

Innovation Solution

Implementing a 'fast mutex' mechanism that combines mutual exclusion locks with automatic priority inheritance, ensuring that threads blocked on a mutex remain on the ready list and cause the mutex-holding thread to run, thereby avoiding context switches and maintaining high-priority scheduling without performance penalties.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional priority inheritance mechanisms are implemented in microkernel designs, then robustness against priority inversion is improved, but computational overhead and performance deteriorate

Engineering Contradiction:
Improverobustness against priority inversionVSAvoidcomputational performance
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent merges mutual exclusion locking with priority inheritance into a unified mechanism. When a thread acquires a mutex, it automatically inherits the priority of any blocked higher-priority threads, eliminating the need for separate priority inheritance protocols and reducing computational overhead while maintaining robustness.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The mutex mechanism is designed to serve multiple functions simultaneously: it provides mutual exclusion, automatic priority inheritance, and scheduling control. This multi-functionality eliminates the need for separate dedicated priority inheritance mechanisms, reducing system complexity and computational overhead.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Speed

If context switches are performed to implement priority inheritance, then high-priority task scheduling is improved, but system performance and efficiency deteriorate

Engineering Contradiction:
Improvehigh-priority task scheduling speedVSAvoidsystem efficiency
Core Design Contradiction:
SpeedVSProductivity

Solution Approach 1:

The system performs preliminary actions by maintaining ready lists organized by priority levels and pre-establishing mutex ownership relationships. When a high-priority thread needs a lock held by a lower-priority thread, the priority inheritance is automatically activated without requiring intermediate context switches, as the scheduling infrastructure is already prepared.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent uses copying of priority information rather than physical context switching. When priority inheritance is needed, the blocked high-priority thread's priority information is copied to the mutex-holding thread, allowing the scheduler to adjust scheduling decisions without forcing an immediate context switch, thus maintaining system efficiency.

Inventive Principle:
Principle #26Copying

Data Source

PatentUS8161481B2Operating system providing a mutual exclusion mechanism
Publication Date: 2012.04.17 NOKIA TECHNOLOGIES OY
  • US8161481B2 patent drawing
  • US8161481B2 patent drawing
  • US8161481B2 patent drawing

AI summary

An operating system for a computing device includes a scheduler incorporating an algorithm for ordering the running of threads of execution having different priorities. The operating system is also arranged to provide a list of threads which are scheduled to run on the device, ordered by priority. At least one locking mechanism for docking access to a resource of the device from all threads except for a thread that holds the locking mechanism is also provided, and the operating system arranges for a scheduled thread which is docked from running because the resource it requires is locked to cause the thread which holds the locking mechanism to run.