Interrupting Real-Time IoT Tasks: How Bad Can It Be to Connect Your Critical Embedded System to the Internet?
Ilja Behnke, Lukas Pirl, Lauritz Thamsen, Robert Danicki, Andreas Polze, Odej Kao
IInterrupting Real-Time IoT Tasks:How Bad Can It Be to Connect Your CriticalEmbedded System to the Internet?
Ilja Behnke ∗ , Lukas Pirl ‡ , Lauritz Thamsen ∗ , Robert Danicki ∗ , Andreas Polze ‡ , and Odej Kao ∗∗ Technische Universit¨at Berlin, Germany, [email protected] ‡ Hasso Plattner Institute, Germany, { first.last } @hpi.de Abstract —Embedded systems have been used to control phys-ical environments for decades. Usually, such use cases requirelow latencies between commands and actions as well as a highpredictability of the expected worst-case delay. To achieve thison small, low-powered microcontrollers, Real-Time OperatingSystems (RTOSs) are used to manage the different tasks onthese machines as deterministically as possible. However, with theadvent of the Internet of Things (IoT) in industrial applications,the same embedded systems are now equipped with network-ing capabilities, possibly endangering critical real-time systemsthrough an open gate to interrupts.This paper presents our initial study of the impact networkconnections can have on real-time embedded systems. Specifically,we look at three aspects: The impact of network-generatedinterrupts, the overhead of the related networking tasks, and thefeasibility of sharing computing resources between networkingand real-time tasks. We conducted experiments on two setups:One treating NICs and drivers as black boxes and one simulatingnetwork interrupts on the machines. The preliminary resultsshow that a critical task performance loss of up to 6.67% perreceived packet per second could be induced where latenessimpacts of 1% per packet per second can be attributed exclusivelyto ISR-generated delays.
Index Terms —Internet of Things, Real-time, Interrupts, CyberPhysical Systems, Embedded Systems
I. I
NTRODUCTION
Embedded devices that control machines in the physicalworld have been part of industrial processes as well as homeand automotive appliances for decades [1]–[3]. In contrastto general-purpose computing, these devices need to fulfilltiming constraints. To this end, Real-Time Operating Systems(RTOSs) are used, which are lightweight and make guaranteestowards the timing predictability of tasks [4]. Usually, a pre-emptive task scheduler allows to configure different prioritiesfor different concurrently active tasks, so that the most time-critical tasks always take precedence over less critical ones.Interrupt Requests (IRQs) are generated by the hardwareand inevitable for systems to function. At the same time,they introduce a level of unpredictability to the process flow.Since the corresponding Interrupt Service Routines (ISRs)are handled by the processor, the scheduler of an OperatingSystem (OS) has no control over their execution. However,by keeping the execution times of ISRs minimal and con- sidering worst-case scenarios during the development, mosttraditional embedded systems can handle IRQs without miss-ing deadlines. Yet, in the past, the environment controlled byembedded systems tended to be self-contained, the numberof environmentally-triggered IRQs was typically small, andtheir impact, therefore, predictable. With the advent of theInternet of Things (IoT) in industrial applications this premisehas changed. IoT microcontrollers come with built-in networkchips and are increasingly often network-connected for thesake of remote control, monitoring, and maintenance [5].IoT networks are, however, open by design and thus lesspoliced [6]. Especially for critical real-time tasks on networkedembedded microcontrollers, this is a threat: The embeddedsystems have to handle the additional resource consumptionof the non-critical networking tasks and the necessary Net-work Interface Controller (NIC) introduces a new source ofunpredictability as incoming packets trigger IRQs that disturbthe flow of scheduled tasks [7]. This might lead to a criticalload of interrupts and triggered network tasks in the RTOS,invalidating real-time guarantees and thereby lowering thesystem’s dependability.This paper analyzes the impact of network loads on criticalreal-time tasks running on state-of-the-art microcontrollerswith modern RTOSs used in the IoT. In an initial study,we evaluate timing measurements of critical tasks on micro-controllers running vendor-supplied RTOSs, network drivers,and network stack tasks under different network-triggered IRQloads. To expose any existing mitigation in the hardware andclosed source drivers, a pseudo network driver is designed toserve as a second IRQ source. Measurements are taken andcompared between real and pseudo network packet processing.Building on our methodology, we perform the followingcontributions: • Measurement of ISR-induced delay to real-time tasks. • Evaluation of overhead induced by networking tasksunder different network loads. • Preliminary analysis of the feasibility of IoT program-ming frameworks and IP networking in real-time scenar-ios.
Outline . The remainder of the paper is structured as fol-lows. Section II presents the problem statement. Section IIIintroduces our evaluation methodology. Section IV presents a r X i v : . [ c s . N I] F e b ur empirical results with two different setups. Section Vdiscusses the results. Section VI describes the related work,while Section VII concludes the paper.II. P ROBLEM S TATEMENT
As motivated, the inclusion of network controllers to em-bedded real-time systems introduces an unpredictable sourceof interrupts. The goal of this work is the analysis of the impactof these interrupts in IoT environments. This includes theexecution of ISRs, network drivers, and network stack tasks, aswell as the robustness of the entire system under high networkloads. This section provides the scope and assumptions of ourwork.
A. IoT Environments
Available IoT devices are microcontrollers possessing themeans to wirelessly connect to networks and handle a multi-tude of different network protocols comparable to the networkstack implementations in general computing. At the sametime, these systems are designed to be deployed in untrustedenvironments, more or less directly connected to the internet[8]. Packet floods generated by faults and security breachesfurthermore lay open potentially critical systems that aredeployed in secluded networks. Due to these circumstances,we consider networked embedded systems of increased vul-nerability while controlling critical systems with real-timeconstraints [9].The high popularity of the IoT led to the mass productionof IP capable devices that are cheaply available. To make thesomewhat complex programming for embedded systems moreavailable in the IoT context, devices come with programmingframeworks masking low-level software like network stacksand drivers. While the investigated modules can technicallyalso be programmed without their respective frameworks, theimmense workload of the implementation and inclusion of thenetwork driver and stack tasks makes this unfeasible in mostcases. An incorporation of the built-in Wi-Fi chips into fullymanageable and transparent real-time systems is hindered bythe unavailability of driver source code.
B. Design and Development for IoT MCUs
During the design and development of real-time systems, thedeveloper is responsible for making sure that any deadlinesare met in the worst-case scenario. In case of externallycaused interrupts, it is therefore necessary for the developer toincorporate the maximum frequency of interrupts and theirimpact into the design of the system. Network-generatedinterrupts however leave the developer only with few choiceslike turning off interrupts or reserving a physical core fornetworking tasks [10]. While both actions might solve theproblem of interrupt floods over the network, the loss of acore (if available) and access to the embedded system fromoutside might not be feasible.Additionally, the limited access to low-level functions leadsto a loss of control over the real-time system, which shouldgenerally be designed holistically.
C. Assumptions
Concluding, we make the following assumptions for ouranalysis. • A1 - Unreliable networks : IoT devices are commonlydeployed in untrustworthy networks and/or might besubject to network faults. • A2 - WiFi : While the issue of unpredictable interruptsis the same across network interfaces, driver availabilityand specific processing costs differ. Wi-Fi connectionsbelong to the most commonly used interfaces, since nomodifications to available hardware has to be made andthe technology is mature. • A3 - Shared Resources : Networking tasks, drivers, andapplication tasks might run on the same MCU core. • A4 - Device-specific frameworks : To implement real-timesystems with Wi-Fi capabilities on IoT devices, device-specific frameworks are used.The design of our experiment setup is deviated from theseassumptions. III. M
ETHODOLOGY
A certain impact of networking tasks and interrupts onMicrocontroller Unit (MCU) utilization and timing predictabil-ity in real-time embedded systems seems inherent. With theexperimental methodology and setup we aim to analyze thisimpact both qualitatively and quantitatively on two currentCommercial Off-The-Shelf (COTS) IoT devices.
A. Experiment Design
For the quantitative analysis we designed two sets of ex-periments observing timing metrics of a periodic task. Theexperiments are run under different network loads with tworegarded interrupt setups (cf. Section III-D). The experimentpermutations were additionally adapted to take into accountthe differences between priorities of preexisting network tasks.
Observed Metrics:
We defined two sets of experimentsobserving different metrics under changing network loads.
1) Lateness:
The critical task we observe is periodicallycalled by a timer with period p and a deadline d . We definethe lateness l as the time the task takes longer to finish thanits deadline allows, hence l = t end − d where t end is the timeat which one process cycle of the task has finished as depictedin Figure 1. Once we reach a load at which the task misses itsdeadline, the lateness will start to accumulate over iterations.We present the accumulated lateness per second.
2) Relative MPU utilization:
In the second set of experi-ments, the observed task runs in a closed loop for a durationof ∆ t in an interval i . By measuring the number of cyclesthe critical task finishes in one ∆ t under different networkloads we can make out the resource utilization of networkingoperations depending on the number of received packets. B. Test Environment
The experiments were performed on two widely used IoTdevelopment boards in similar performance and price ranges.One equipped with a dual-core ESP32 chip at 160 MHz, the ime observedtask d1 d2tend tendl1 l2p dd observedtask
Fig. 1: Lateness measurements.other with a Particle Photon (P0) single-core ARM Cortex M3at 120 MHz. While both devices have ports of the FreeRTOSoperating system, the vendor-provided programming frame-works differ significantly in terms of programmability and portspecific implementations. Both devices are programmed usingtheir respective frameworks. While the frameworks them-selves and operating systems are open source, some low-levelsoftware such as Wi-Fi drivers are only available as binaryobjects. While the differences between frameworks and usedprocessing chips limit the degree of direct comparability, theyallow us to evaluate the possibilities of development inside theframeworks’ constraints. This way, all results are realistic forthe systems tested under their established workflows.
C. Task Priorities
To keep the connections alive, driver and networking taskshave to be kept running on the devices. These are called byNIC-triggered ISRs but can be preempted by a higher priori-tized task on the same core.To evaluate the different shares ofdelays caused by ISRs and networking tasks, experiments arerepeated with observed task priorities chosen above, equal to,and below the driver. The default networking task and driverpriorities are specified by the frameworks as depicted in TableI. Wi-Fi driver priorities cannot be changed.TABLE I: Networking task priorities module in firmwares prio ESP32 P0 prio - Wi-Fi driver Wi-Fi driver network (high) - network (low) network -
D. Interrupt Workload
To analyze the impact on lateness and computing resourceutilization, the devices under test are put under differentnetwork loads.
Generation:
One of the main difficulties when investigatingthe process flow a received packet triggers is the unavailabilityof large parts of the driver source code. Quantitatively analyz-ing the number of times an ISR is effectively called is thereforedifficult to realize. To be able to compare the relative impactof ISRs and low-level packet processing, two interrupt setupsare run on the devices.
1) Real Network Packets:
In the first setup, network packetsare sent to the devices over a Wi-Fi connection and are handledby the framework-supplied driver and networking tasks (Figure2a). We use the second core of the ESP32 to run a minimallyconfigured UDP server to measure its impact. As the P0 doesnot have a dual-core processor, no UDP server was run andinterrupts were generated externally.
2) Simulated Packets:
Secondly, we implemented an anal-ogous task flow to perform Wi-Fi driver independent ex-periments (Figure 2b). A networking task simulation largelyperforms the same actions a packet received over a networktriggers: Upon registering the interrupt which in this case istriggered via an input pin, a short ISR is called that preemptsthe currently running process to copy a packet descriptor toa FreeRTOS queue. A pseudo driver task waits for packets inthis queue and unblocks when it is not empty to process theentries. observed taskWi-Fi drivernetwork task core 1
UDP server core 2 mailbox monitoring queue (a) Wi-Fi driver observed tasknetwork task irqqueue core 2core 1 monitoringtraffic generatorpseudo driver (b) network simulator
Fig. 2: Experiment setups on ESP32.
Traffic Loads:
Changes in network load directly affect thenumber of ISR, driver, and network stack calls in the operatingsystem. Depending on the system and interrupt type, networkloads were increased in steps of 10, 100, or 1,000 packetsper second and held to take measurements. Additionally,experiments were conducted with traffic bursts of 120,000packets per second for one second.IV. E
XPERIMENTAL R ESULTS
This section presents our preliminary empirical results ofhow interrupt loads impact the lateness of critical tasks andutilization of CPUs.
A. Lateness ExperimentsESP32:
The first group of experiments was conducted tomeasure the lateness of the observed task under rising packetloads. Figures 3a and 3b contain the lateness results undersimulated and real network traffics on the ESP32. Both show alinear increase in lateness with rising packet load once latenessoccurs for priorities chosen below the driver priory with realIP packet impact reaching 50% lateness increase per packetper second. The differences between priorities correspond to . · packets / s l a t e n e ss [ m s ] p-p+(a) ESP32, simulated network traffic packets / s l a t e n e ss [ m s ] p- boundp+p- (b) ESP32, real IP packets packets / s l a t e n e ss [ m s ] p-p+(c) P0, real IP packets Fig. 3: Lateness experiment results with observed task priorities under networking tasks (p-) and critical (p+). . · packets / s t a s k c y c l e s / s p-p+(a) P0, simulated network packets packets / s t a s k c y c l e s / s p-pd(b) ESP32, real IP packets, unbound port packets / s t a s k c y c l e s / s p-p+(c) P0, real IP packets Fig. 4: Task cycle counter experiment results with observed task priorities under networking tasks (p-), critical (p+), and equalwith wi-fi driver (pd).the preemption of the fixed networking tasks once the MCUsare fully utilized. When the observed task has a lower prioritythan the networking tasks, it starves once too many packetsarrive. When the observed task has a critical priority, it in turnstarves the networking tasks. As can be seen this results in noimpact, suggesting that no ISRs are triggered by the NIC inthis case.Figure 3b also shows that the impact of incoming packets isa lot higher when addressed to a port that is not listened on.This might be due to the partial deactivation of networkingtasks when UDP buffers in the network stack are full.Lateness results under traffic bursts do not differ fromcontinuous loads and no other influence to the systems couldbe seen. Further burst results are therefor omitted from thiswork as this was true for all burst experiments.
P0:
Figure 3c contains the analogous results of the ex-periments on the P0. The results of the simulated approachare very similar to the ESP32 equivalent, with the differencein slope explainable by platform specific pseudo driver im-plementations. The results from the experiments using realnetwork packets show an impact slope of 2.2%. The resultsalso show issue of the network driver residing on the highestpriority level. Once the packet load is high enough that thenetwork driver needs half of the computing resources for itself,the operating system’s scheduler distributes the processingresources equally between the driver and the observed (critical) task. In contrast to ESP32 task, the observed task here doesnot starve when of lower priority. Before this can happen, theWi-Fi task crashes at 980 packets per second.
B. Utilization Experiments
Figure 4 contains the parallel results for real networkpackets and software. Task priorities of the presented resultswere chosen equal to and lower than the Wi-Fi driver. Taskperformance decreases by 2.15% and 3.8% respectively. Whenreceiving packets on an unused port the impact is again higherwith performance decreases of 3.17% and 6.67% respectively.Figure 4a contains the results for the network driver simu-lation on the P0, which are comparable to the lateness results.With real network packets the system crashes at 980 packetsper second when giving the observed task a lower priority thanthe Wi-Fi driver and at 2,000 packets per second with the samepriority. Task performance decreases by 2% per packet persecond until equal resource utilization with the driver (samepriority) or throughout gradual extrusion by it (lower priority).V. D
ISCUSSION
This section discusses the findings from the experimentsand the feasibility of IP networking on MCUs.
A. Insights from the Experiment Results
The evaluation results show that the performance and real-timeness, is directly dependent on incoming IP network load. high overhead generated by the receiving of packets canbe seen in continuous floods as well as short transmissionbursts. The Wi-Fi driver and network stack utilize any computeresources they need to handle packets unless preempted. Yet,the results also show that NIC-triggered ISRs have no impacton the observed systems. This observation is made whenincoming packets are not handled due to the driver beingpreempted by a task of critical priority.To mitigate the observed breaking of real-time guarantees onthe tested devices, developers still have some options. The ESPIDF provides one priority level above the Wi-Fi task’s priority.Running a critical task here will preempt the driver. For criticalcode sections it is also possible to disable all or only the Wi-Fiinterrupt. This is the only option under Particle’s DeviceOS.
B. Feasibility of IP Networking
The main take away is that it is necessary to fit all mission-critical operations into a critical task that is independent ofany signals received over the network. Hence, performingcommand and control operations over the network cannot bean option for real-time systems. This however invalidates mostIoT use-cases.Network driver tasks, which are responsible for a large shareof the impact on timing predictability and hence lateness, arevery highly prioritized in the tested systems’ frameworks. Thishighly limits the margin critical tasks have. While short andindependent tasks and code blocks can be executed in a safemanner, this is also where it ends.Network driver tasks are currently given a priority level inRTOSs that is not suitable for critical real-time systems. Usingnetwork connectivity only for monitoring timing independenttasks might still be an option when one is ready to providethe resources and prioritize the necessary tasks appropriately.
C. Networking Software Robustness
Current IoT device programming frameworks seem to bedesigned for certain connectivity guarantees rather than real-timeness of critical applications. However, this also does nothold for the evaluated systems as can be seen from theresults. Under the conditions of the test setup, even lowtraffic loads lead to Wi-Fi driver crashes and, depending onthe framework configuration, to system halts. This could bereliably reproduced on the P0 (cf. Figure 4c).
D. Summary
Following points can be taken from our work: • If no explicit care is taken, networking has a huge impacton the real-timeness of embedded systems, rendering real-time guarantees invalid. • The empirically observed problems are largely introducedby IoT programming frameworks rather than the generalarchitecture. • Transmitting command and control signals over an IPnetwork is not feasible for tasks that need hard real-timeguarantees. • The inflexibility of current network stack implemen-tations and the high networking overhead suggest thereservation of a separate core for networking software.This might not be worth the cost since the previous pointholds true for dual-core modules. • Limited access to network related tasks prevent a holis-tic real-time system design and cooperative schedulingbetween them and programmed tasks.VI. R
ELATED W ORK
Addressing the unwanted impact of interrupts is beingresearched since decades. So, to understand today’s commoninterrupt handling mechanisms, it is helpful to understand theevolution of those mechanisms. The first part of this sectionwill hence briefly outline implementations that pioneeredconcepts which are relevant up until today. Thereafter, wepresent scientific works which address the impact of IRQson embedded real-time systems and applications.
A. Basic Interrupt Handling Mechanisms
The
LynxOS
RTOS has introduced the concept of runningre-entrant network protocol stacks in the priority spectrum ofa receiver’s process. By de-multiplexing network traffic at theNIC level, low latency for processing real-time network trafficcan be guaranteed. LynxOS claims to be the first system builton an architecture that separates ISRs and Interrupt ServiceTasks (ISTs) (i.e., light weight kernel tasks) [11].The
SUN (now
Oracle ) Solaris
OS [12] is another promi-nent example for implementing interrupt handling within thepriority spectrum of regular process and thread scheduling. So-laris distinguishes real-time, system, and time-sharing schedul-ing classes. With these priority spectrums, Solaris was able toeffectively isolate real-time processing from networking.
Windows Embedded Compact ( Windows CE ) [13], is anOS family developed for handheld consumer electronics (CE)devices. Interrupt handling is divided among the kernel anda process running all device drivers. By running networkhandlers with a priority lower than the one used for real-timetasks, Windows CE effectively is able to implement isolationand call admission for incoming network activities.These OSs served millions of industrial applications inpractice and the influences of their concepts can still be foundtoday. Nevertheless, applications, their surrounding environ-ments, and their underlying hardware have changed, whereeven entry-level hardware has complex performance fea-tures.All together, these developments complicate the timingpredictability and existing knowledge needs to be confirmedor refined with up-to-date numbers.
B. Advanced Interrupt Handling
Several works have identified the duality in priority spacesas still being a challenge for RTOSs and applications.A class of approaches tries to mitigate the unwanted effectswith additional hardware. This hardware usually intercepts theIRQs between their source and the CPU. Gomes et al. proposeo extend the interrupt controller with a task-aware prioritycontroller [14]. This controller compares the priority of anincoming IRQ with the priority of the currently running taskand avoids that lower-priority tasks preempt higher-prioritytasks. In a proposal by Leyva-del-Foyo et al. a custom interruptcontroller [15] is used to realize dynamic priorities for theIRQ lines. Additionally, all ISRs become ISTs, which enablesthe Field-Programmable Gate Array (FPGA) to unify theirsynchronization and scheduling. While these solutions promiseto have little overhead, the requirements of additional interrupthardware can not be met with COTS microcontrollers.Other works try to mitigate the unwanted effects usingsoftware-only. In [16], Leyva-del-Foyo et al. enhance theapplicability of their concept presented in [15] with an im-plementation for standard PC interrupt hardware. Ober et al.patented a solution where the decision whether to wake anIST or not is based on a unique priority per task and a globalinterrupt priority value [17].Prominent work regarding the unification of priority spacesis the approach implemented in the
Sloth
OS [18], [19].Instead of using a software scheduler for threads, every controlflow is designed as a thread-related system call using thehardware interrupt system. By letting the hardware manageall control flows, ISRs and (other) threads preempt each otherin accordance with their priorities.Although sophisticated mitigation approaches are beingdeveloped, only a few works quantify the impact of IRQloads on real-time tasks. In [20], the authors explicitly specifythe IRQ load caused with network packets (20 Hz) whilemeasuring ISR latencies. Furthermore, Regehr et al. presenta collection of approximate IRQ frequencies [21].The research described shows that there are promisingsolutions for an improved latency or efficiency of interrupthandling. However, none of the examined papers focus on theimpact of IRQs on real-time tasks and do not quantify theeffects directly. VII. C
ONCLUSION
The IoT introduces network interfaces and full IP stacks tomicrocontrollers running real-time applications. These open upthe systems to interrupts network-triggered IRQs. We thereforeanalyzed the impact of network packet floods to the latenessand performance of real-time tasks on two state-of-the-art IoTMCUs. Our results show that the execution of network stacktasks on IoT devices can pose a significant threat to real-time guarantees and that the ISR executions themselves havea similar, yet less severe impact on critically prioritized tasksin comparison to the entire packet handling.The results have shown that a more comprehensive studywith a broader range of IoT devices and test scenarios is inorder. Furthermore, we will investigate mitigation techniquesfor NIC-generated ISR delays in real-time systems.A
CKNOWLEDGMENTS
We thank Martin Haug and Laurenz M¨adje for their supportduring experiment implementations. R
EFERENCES[1] A. Malinowski and H. Yu, “Comparison of embedded system design forindustrial applications,”
IEEE Transactions on Industrial Informatics ,vol. 7, no. 2, pp. 244–254, 2011.[2] Chen Youdong, Wei Hongxing, and Wang Tianmiao, “Embedded controlsystem for industrial robots,” in , vol. 5,2010, pp. 122–125.[3] Bin Li and Jinhui Lei, “Design of industrial temperature monitoringsystem based on single chip microcontroller,” in , 2011, pp.342–344.[4] T. N. B. Anh and S. Tan, “Real-time operating systems for smallmicrocontrollers,”
IEEE Micro , vol. 29, no. 5, pp. 30–45, 2009.[5] S. Nuratch, “The iiot devices to cloud gateway design and implemen-tation based on microcontroller for real-time monitoring and controlin automation systems,” in , 2017, pp. 919–923.[6] C. Zhang and R. Green, “Communication security in internet of thing:preventive measure and avoid ddos attack over iot network,” in
Pro-ceedings of the 18th Symposium on Communications & Networking , pp.8–15.[7] C. Dovrolis, B. Thayer, and P. Ramanathan, “Hip: hybrid interrupt-polling for the network interface,”
ACM SIGOPS Operating SystemsReview , vol. 35, no. 4, pp. 50–60, 2001.[8] H. Petersen, M. Lenders, M. W¨ahlisch, O. Hahm, and E. Baccelli, “Oldwine in new skins? revisiting the software architecture for ip networkstacks on constrained iot devices,” in
Proceedings of the 2015 Workshopon IoT Challenges in Mobile and Industrial Systems , ser. IoT-Sys ’15.ACM, 2015, p. 31–35.[9] X. Bellekens, A. Seeam, K. Nieradzinska, C. Tachtatzis, A. Cleary,R. Atkinson, and I. Andonovic, “Cyber-physical-security model forsafety-critical iot infrastructures,” in
Wireless World Research ForumMeeting , vol. 35, 2015, p. 18.[10] N. Klingensmith and S. Banerjee, “Hermes: A real time hypervisorfor mobile and iot systems,” in
Proceedings of the 19th InternationalWorkshop on Mobile Computing Systems & Applications
IEEE Embedded Systems Letters , vol. 7, no. 1,pp. 27–30, 2015.[15] L. E. Leyva-del Foyo and P. Mejia-Alvarez, “Custom interrupt manage-ment for real-time and embedded system kernels,” in
Proceedings ofthe Embedded Real-Time Systems Implementation Workshop at the 25thIEEE International Real-Time Systems Symposium (RTSS’04) . IEEE.[16] L. E. Leyva-del Foyo, P. Mejia-Alvarez, and D. de Niz, “Predictableinterrupt management for real time kernels over conventional pc hard-ware,” in . IEEE, pp. 14–23.[17] R. E. Ober, R. D. Arnold, D. F. Martin, and E. K. Norden, “Interrupt andtrap handling in an embedded multi-thread processor to avoid priorityinversion and maintain real-time operation,” Patent US Patent 7,774,585.[18] W. Hofer, D. Lohmann, F. Scheler, and W. Schr¨oder-Preikschat, “Sloth:Threads as interrupts,” in . IEEE, 2009, pp. 204–213.[19] W. Hofer, D. Lohmann, and W. Schr¨oder-Preikschat, “Sleepy sloth:Threads as interrupts as threads,” in . IEEE, 2011, pp. 67–77.[20] P. Regnier, G. Lima, and L. Barreto, “Evaluation of interrupt handlingtimeliness in real-time linux operating systems,”
SIGOPS Oper. Syst.Rev. , vol. 42, no. 6, p. 52–63, 2008.[21] J. Regehr and U. Duongsaa, “Preventing interrupt overload,”