Avoiding Shared Resources

In LabWindows/CVI, there are resources that two or more threads might need to share. Shared resources can cause jitter and prevent applications from taking advantage of multiple CPUs. Common examples of shared resources include the following:

• Thread safe variables (Utility Library)
• Thread locks (Utility Library)
• The memory manager
• Single-threaded DLLs

If a thread uses a shared resource, the thread acquires an operating system mutex around the resource to protect the resource from access by other threads. A mutex can be held only by one thread at a time so that other threads may not access the associated resource. If a higher priority thread preempts a lower priority thread and attempts to use a locked resource, the higher priority thread must wait because the shared resource is not available. The lower priority thread becomes more important than the higher priority thread because it must finish its work and release the shared resource before the higher priority thread can proceed. This scenario is a priority inversion and can affect determinism.

Memory Allocations and Preallocating Arrays

When a thread allocates memory, the thread accesses the memory manager. The memory manager allocates memory for data storage. The memory manager is a shared resource and might be locked by a mutex for up to several milliseconds. Allocating memory within deterministic code can affect the determinism of the code.

If you are using arrays in deterministic loops, you can reduce jitter by preallocating the arrays before entering the loops.