Table Of Contents

Scheduling Behavior in Real-Time Operating Systems

Version:
    Last Modified: April 18, 2016

    The way a real-time operating system (RTOS) schedules tasks guarantees that high-priority tasks execute within precise time constraints. Understanding how scheduling works in an RTOS can help you set the right priorities for deterministic tasks in your application.

    The following list contains some key concepts that underlie the RTOS scheduling process:

    • Thread—The basic unit of concurrency in a real-time system. Operations within a thread execute sequentially, while each thread executes independently of other threads.
      spd-note-note
      Note  

      Even if you place parallel code inside a Timed Loop, LabVIEW executes the code sequentially because each Timed Loop runs on only one thread.

    • RTOS scheduler—An algorithm the RTOS uses to schedule threads. The RTOS scheduler determines which thread to run on each CPU in the system at any given time.
    • Run queue—The queue of threads ready to be scheduled. Threads in the run queue are either executing or ready to execute.
    • Timed Loop priority—The priority you assigned to a Timed Loop using priority in on the Execution System border node. Timed Loop priorities are numeric, and a higher value represents a higher priority relative to other Timed Loops executing on the controller.
      spd-note-note
      Note  

      National Instruments recommends creating no more than one Timed Loop per CPU core on your real-time controller. Setting more than 32 unique Timed Loop priority levels on an RT controller causes LabVIEW to return an error.

    • Priority-based scheduling—A scheduling policy in which threads are scheduled according to priority.

    Thread States

    At any given time, every thread in a real-time system is either running or blocked.

    • Running—The thread is in the run queue. When a thread begins executing, it runs until it meets one of the following conditions:
      • The thread finishes executing.
      • The thread is preempted by a higher-priority thread.
      • The thread becomes blocked by the built-in timing mechanism of a Timed Loop or by a blocking node, such as the Wait node within a While Loop.
    • Blocked—The thread cannot execute until some event occurs, such as the completion of an I/O operation or a timing node.

    When a thread becomes unblocked, it enters the run queue in order of priority.

    Priority-Based Scheduling of Timed Loops

    The RTOS scheduler handles new Timed Loop threads that enter the run queue in different ways depending on their priorities.

    Use the following table to decide how to set relative priorities for Timed Loops in a real-time application so that the application meets timing requirements.

    Priority of new Timed Loop thread RTOS scheduler behavior
    Higher priority than running thread The scheduler preempts the running thread so that the new thread can execute immediately. The preempted thread then moves behind the new thread in the run queue.
    Equal priority as running thread The scheduler places the new thread behind all other threads of the same priority in the run queue. Threads of equal priority are scheduled according to a first-in, first-out policy.
    Lower priority than running thread The scheduler allows the new thread to run only after all higher-priority threads are blocked.
    spd-note-note
    Note  

    Although it seems intuitive to set the priority of each loop based on the importance of the loop, this strategy can cause jitter. Instead, set the priority of each loop based on how important it is for the task fulfill a certain timing guarantee.


    Recently Viewed Topics