07-30-2015 04:49 PM
I have a cluster called "Inputs" which has a bunch of data inside of all kinds of data-types.
I have several loops in the code that I want each one of them to update a specific element inside the cluster.
To do that I need to get the cluster, use Bundle by Name on the specific element and then write it back to the cluster.
That way I can have race conditions because two loops can "get" the cluster at the same time but when they write back one wiil overwrite the other.
How can I avoid those race conditions?
I'm familliar with Functional Globals if it is connected to a possible solution (I have a feeling it is..)
Thank you!
Solved! Go to Solution.
07-30-2015 04:55 PM
It would be helpful if you could post your code so that we can better understand your situation. Are your loops nested inside each other? Are they running in parallel? Are you storing this cluster in a shift register, is it a control whose value you access with a local variable, or do you store it another way? These questions and others would be answered if we could see your code.
07-30-2015 05:03 PM
This is not a real code beacuse I'm just testing a new way to code a robot, but we can discuss the issue using this example.
The loops are running in parallel and each of them is updating a specific cluster element without cahnging the others.
The controls represent the new data.
07-30-2015 05:17 PM - edited 07-30-2015 05:19 PM
What else accesses that global variable? More than you show?
Use a non-reentrant subVI to keep the cluster in an action engine and do the updating. How many elements are there?
You could use an additional loop that keeps the cluster in a shift regsiter and use queues to replay update information form each loop.
You could also use a data value reference for the cluster.
There are many solutions!
07-30-2015 05:17 PM - edited 07-30-2015 05:20 PM
This is not my initial response. This is me basically trying to delete my initial response. Sorry about that.
07-30-2015 05:20 PM
I recommend that you don't use global variables, because they make it difficult to maintain your code. Imagine the following scenario: you have three different loops running at the same time, each loop accesses the global five different times. Now you start testing your code, and you notice that one of the entries in your global variable starts displaying the wrong value after five minutes. How would you find the root of this problem?
Functional global variables suffer from the same drawback. They do prevent race conditions (as you suggest), but they still cause a lot of difficulty when you are debugging.
What do you want this program to do? Why do you want to store this data in a global variable?
07-30-2015 05:24 PM - edited 07-30-2015 05:25 PM
If you have multiple loops running that are all updating the same cluster, I think a simple solution would be to divvy up your cluster further into parts that are appropriate for that while loop then...use queues to update main cluster. A separate loop that dequeues data and updates the main data cluster! Or you could use notifiers. Or... you could use synchronize. Thoughts NI world?
07-30-2015 05:24 PM - edited 07-30-2015 05:27 PM
There is a main loop that reads the cluster into a subVI, and there might be other sources that will update the cluster.
Can you give me examples for your solutions? I don't think I understand how to implement this.
I'm using a cluster beacuse LabVIEW statecharts accept a cluster of inputs which I want to update from various sources.
A global variable is what I know so I tried it.
07-30-2015 05:36 PM - edited 07-30-2015 05:42 PM
Yeah, sorry about that. It dawned on me what it was you were asking after I posted.
This is a solid solution. Quick mock up. You can do thing bundle the data with its data type and queue that, then use that info after dequeue to determine which value in the cluster it needs to go to. But this will certain remove race conditions.
07-30-2015 05:41 PM - edited 07-30-2015 05:45 PM
I still think my suggestion of using data value references would be simplest. The IPE structure will block concurrent access to the data cluster: No race condition.
The last loop (optional) shows how to query the state of the data cluster.