To preempt or not to preempt, that is the question

Authors

Bernard Blackham, Vernon Tang and Gernot Heiser

NICTA, Sydney, Australia
UNSW, Australia

Abstract

Real-time operating systems (RTOSes) are traditionally designed to be fully preemptible. This improves the average interrupt response time of the system but increases kernel complexity. An alternative design is to make the kernel mostly non-preemptible and only handle pending interrupts at specific preemption points within the kernel. It is often said that this design leads to poor interrupt response times. However, for hard real-time systems the key requirement is on worst-case interrupt latencies. We claim that for a protected-mode RTOS, as required for multi-criticality systems, non-preemptible kernels can achieve worst-case latencies comparable to those of fully-preemptible kernels.

In order to understand the latency limits achievable in both approaches, we analyse and compare the worst-case interrupt latencies of a fully-preemptible commercial RTOS (QNX) and a non-preemptible real-time kernel (seL4). Our results indicate that a non-preemptible kernel can achieve interrupt latencies which are within a factor of two from those exhibited by a fully-preemptible kernel.

Copyright © 2012, ACM. This is the author's version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in the proceedings of APSys '12, July 23-24, 2012, Seoul, Korea.

BibTeX Entry

  @inproceedings{Blackham_TH_12,
    numpages         = {7},
    doi              = {10.1145/2349896.2349904},
    author           = {Bernard Blackham and Vernon Tang and Gernot Heiser},
    month            = {jul},
    year             = {2012},
    title            = {To Preempt or Not To Preempt, That Is the Question},
    articleno        = {8},
    booktitle        = {Proceedings of the 3rd Asia-Pacific Workshop on Systems (APSys)},
    pages            = {8:1--8:7},
    address          = {Seoul, Korea}
  }

Download

Served by Apache on Linux on seL4