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

[joptimus]

Hi!

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:

http://labviewjournal.com/2011/08/race-conditions-and-functional-global-variables-in-labview/

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?

[jwscs]

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

[drjdpowell]

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.

[Kevin_Price]

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

[Yamaeda]

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).

/Y

[crossrulz]

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.