There is a very good white paper on using multi-threading that is included in PDF format with the online documentation for CVI that explains how to set up a thread pool and thread callback functions to use it. This same paper discusses thread-safe variables and thread-safe queues. It's actually not too difficult to use these CVI functions to create a multi-threaded application, it is much easier to use these facilities than it is to do it using SDK functions. The architecture I generally use is that all UI access is done in the main program and I create additional threads to handle instrument I/O and data logging.
A thread-safe variable is one that must be accessed using a set of access methods that ensure that only a single thread can modify that variable at a time. These access methods place locks on the variable until a thread is done with it, this ensures that only one thread can write to it, all others have to wait until the lock is released. I generally use this sort of variable to maintain the state of my application by setting up flags or semaphores to reflect test status and other things needed to coordinate what is going on between the user interface, the instrument I/O and the data logging threads.
A thread-safe queue is a data structure that allows messages to be passed between multiple threads that ensures that the data is accessed in the same order in which it was inserted into the queue. Basically it is a FIFO type structure that triggers the calling of a callback function to process the queue data when data is added to it. For example, I use this for data logging in my applications. I add status and error messages to the queue and let the data logging thread display and log it as it has time to get to it. This is especially effective in cases where I run into network lag. Instead of waiting for the program to finish writing data to the network log directory, my program can continue running while the file writing is being done in the background without slowing the rest of the program down.
How difficult it would be to integrate multi-threading into your application is not something I can answer without seeing the code. If you already have things pretty well partitioned and call common functions from your DLLs to do the panel updates, it would be pretty easy. If all of your UI updates are scattered around the DLLs, that may be more difficult. Ideally, you would want to design a multi-threaded application to work that way from the beginning but it may be possible to retrofit another application if necessary.
I hope this helps.
Martin Fredrickson
Test Engineer
Northrop Grumman
Advanced Systems and Products
San Diego, CA 92128
