Last edit: 05-03-17 Graham Wideman

Data Acquisition

Motivation

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:

• If LabVIEW plays within the OS's scheduling mechanism, then existing published characterizations of the scheduling behavior would apply also to LabVIEW.
   
• If LabVIEW uses a scheduling strategy outside the OS's mechanisms, then conceivably apps developed in LV could achieve greater performance than those developed with other traditional environments.

The Basis of LabVIEW Timing Mechanisms

In a discussion over the info-labview@pica.army.mil 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: gam@natinst.com (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:

• Calculate the wakeup delay, put a high priority thread asleep for delay ms.
• The thread that executed the wait function either starts executing parallel code that was already on the execution queue, or it calls WaitForSingleEvent.
• When the high priority thread wakes up from sleep, it signals the waiting thread if necessary and transfers the node information to the execution queue.
• The execution system thread can then resume the diagram code based on normal scheduling rules, and the high prioroty occurrence thread either goes to sleep for the next delay amount or calls WaitOnSingleEvent for another occurrence to be put on the list.

Conclusions

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: