gw_logo_08.gif (1982 bytes) 
Last edit: 05-03-17 Graham Wideman
Data Acquisition
LabVIEW Timing Mechanism
Article created: 99-06-16


I recently pursued the question of whether or not LabVIEW works within the thread-scheduling mechanism provided by the operating system, or whether it might be replacing or otherwise subverting it.  I wanted to know this for two main reasons:

The Basis of LabVIEW Timing Mechanisms

In a discussion over the email list, Grag McKaskle was kind enough to provide a description of what LabVIEW timing is based upon.

Date: Tue, 15 Jun 1999 06:47:00 -0500
From: (Greg McKaskle)
Subject: Re: [W] Timing Quality?
Organization: National Instruments

The two wait functions, plus the timeouts on occurrences are all based on the same mechanism. Arithmetic is done to determine how long the node needs to suspend execution, and it sets up an occurrence. The occurrence manager keeps all of the timeout items sorted on a list, and it has a thread that calls Sleep with the smallest timeout in millisecs.

On nonwindows OSes with threads it may call nanosleep or other various functions for the OS to wake up the thread in N ms. For OSes without threads, this list is polled from time to time from the execution system to notice when occurrences have timed out and to schedule them. 

Occurrences with a wait of 0 ms are never put on this list, and in fact wait nodes with 0 ms never even generate an occurrence, they are a special lower overhead case depending on the threading model.

Once the occurrences have been dispatched, the nodes have being scheduled on their various execution system queues. The execution system is either busy executing other code, or it has a thread waiting to execute (waiting on an event).  If there is a waiting thread, the thread will be signaled in the process of queuing the node. If there are no threads available for that execution system, it will wait until the diagram code yields and schedules the next node in the queue.

If there are lots of wait functions going off in parallel, which includes all running VIs within one LV runtime, then it is up to LV as to what order they are queued in, and it is then up to the OS as to which order the threads that were signaled, get scheduled in and how the scheduling happens between the threads.

In summary, for a single wait function, the operations are:


Greg's answer confirms that LabVIEW works within the OS's scheduling mechanism, but given those constraints goes to great lengths to make the most of it.  

This suggests that applications written in other environments could achieve performance equal to a LabVIEW application, but if the application requires complex parallel operations the non-LabVIEW implementation would require considerable effort to match the internal scheduling strategies already provided by LabVIEW.

[Up to: LabVIEW Timing Topics]

Go to:  gw_logo_08.gif (1982 bytes)