04-01-2015 07:49 AM
04-01-2015 07:53 AM
04-01-2015 07:53 AM
@SaranVenkateshS wrote:
thanks ..actual I roughly made this code to ask question about local variable . if variable value needs in many loops means. ..
If you are talking about a file, I would recommend going the Action Engine route. Or if your values are "constant" (ie only written to at the start of your program), the Global Variables work very well.
Never use the Value property. It is thousands of times slower than a local variable.
04-01-2015 07:58 AM
04-01-2015 08:29 AM
@SaranVenkateshS wrote:
I read many thread. it says dont use local variable . thats why I am using property value.
okay if some variables are changeable means. any other option.
Using a property node is a worse option than using a local variable. It is far less effecient and has the same problems. Take a look at the action engine that crossrulz linked. It is likely the best solution for your exact case.
Here is a link to a zip file you can download to take a look at them
https://decibel.ni.com/content/docs/DOC-2143
04-01-2015 08:33 AM
04-01-2015 08:38 AM
@SaranVenkateshS wrote:
I read many thread. it says dont use local variable . thats why I am using property value.
And that is why that is my #1 pet peeve.
It is very common that people just say "Don't use local variables" without stating why. The use of local variables introduce all kinds of interesting race conditions (multiple places trying to write to the same location, mostly). The use of the Value property node does not fix the issue of race conditions and it just slows everything down A LOT (I am completely serious when I say THOUSANDS of times slower).
I made this document when I was making up a presentation for an internal user group. It shows the dangers of race conditions and a few of the ways people attempt to avoid them. A Look at Race Conditions
04-01-2015 08:44 AM
04-01-2015 10:03 AM
@crossrulz wrote:
I made this document when I was making up a presentation for an internal user group. It shows the dangers of race conditions and a few of the ways people attempt to avoid them. A Look at Race Conditions
That is a fantastic demonstration of the issues with race conditions. Thank you.
07-27-2015 02:27 PM - edited 07-27-2015 02:49 PM
Ok, related question - I open a few UDP sockets at the top of my program, and then need to use them for the duration of execution. I've got a fat case statement (> 30 cases) determing execution of the program, and some of the cases use the sockets. The last guy on this project decided that he'd tunnel the sockets into every case, and shift-register them around the enclosing "while" loop; this leads to a lot of wires running around that are only connected to tunnels. I was thinking about opening the sockets, writing them to an indicator (refnum), and then reading from that indicator (via a local variable) every time I need the socket. I know that the only benefit I get from the local variable solution is a cleaner block diagram, but if I'm never writing to the refnum, except at the beginning and end, I don't need to worry about data races. My question is - will it hurt me in some other way? Does it speed up execution to tunnel these variables around, even when they are not needed, or is it faster to chuck them in some memory bin which only gets read when necessary?
Edit - I only have one VI, but the comment above suggests that global variables would work in this situation: any reason to use a global over a local?