Showing results for 
Search instead for 
Did you mean: 

Best way to pass data between parallel VIs and don't get race conditions?



I need to transfer data between different levels of my architecture:

  • top level: GUI and overall program control
  • middle level: process control
  • low level: instrument control

All my levels incorporate state machines with a consumer/producer architecture with queues.

I pass messages and message data from top to bottom with queues, that works just fine.


But I don't know if queues are the best option to pass data back up the hierarchy.

Top down it is easy: The lower VIs wait (or run a default case) until some message is received (start process 1, turn motor on etc.).

But bottom up is not so clear: The higher level VIs, especially the GUI, need to be responsive to user input, so I really don't want to insert new messages (or cases) that would fiddle with the overall program flow just to get a status update from an instrument.

Currently I read the instrument statii with globals, but I want to change that.

I thought about FGVs, but then I read this:


It seems to me that FGVs don't automatically avoid race conditions?

Maybe I should stick to queues, or is there some other better option?

0 Kudos
Message 1 of 6

hi joptimus,


queues are the main way to transport inforamtion between different parts of your program. i use them as well for the bottom-up part you describe.

you could use globals/FGVs as well, but as you posted there are race-conditions.

Using User Events (which also uses queues) may also be a good way to transport state-machine-triggers. A datatype has to be specified for each user event, so you can transport information as well.


I have asynchronous vis with multiple parallel loops which need to transfer states/information between them (the loops). for this i use local variables (i know its frowned upon, but i hate the wiring more than i hate the memory penalty or the documentation, bc. with wires you see what depends on what, but with local variables you might have the same situation as ... goto-is-considered-harmful) and encapsulate them in a case-strucuture, that is guarded by a semaphore.


hope that might help

If Tetris has taught me anything, it's errors pile up and accomplishments disappear.
0 Kudos
Message 2 of 6

Use your queues, and just make sure new messages are handled quickly.  Handling an update off of a queue can be just as fast as reading an FGV, and doesn't require polling.  The User will not notice the <1ms it takes to update something.

0 Kudos
Message 3 of 6

As said before, it would be natural to use the queues in your architecture as the mechanism for delivering data and state info.  Delivering via queue allows you to act on data the very moment it's freshest, something you can't know with local variables or FGV's.


I often set my low-level loops to publish data on a regular basis.  Higher-level loops receive it, update their state info to account for it, and can decide whether to take further action.  Sometimes, I also build in support for on-demand querying, i.e., high level loop sends a request for data to be returned immediately.



-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 6

Send queues down the hierarchy (like you're doing), the Events up. 🙂 That way you can scale it up with more listeners if the application needs to grow. It's also the basic design idea of Queues = Many to one, Events = one to many (producers/listeners).


G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
0 Kudos
Message 5 of 6

If you are already recieving data with queues, use queues to send data to that loop (thinking about your middle loop here).  You GUI loop should not have a queue.  GUIs need the Event Structure.  Therefore, use User Events to send data back up to the GUI loop.

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 6