Unitialized Variable values?

[Grub]

When I write an unitnitialized shift register into my code, what value is in there?  Can there be junk from old memory use in there, or is there a default value, null value, or what?

Grub

[Will.D]

From the LabVIEW Help...

"If you do not initialize the register, the loop uses the value written to the register when the loop last executed or the default value for the data type if the loop has never executed."

[Grub]

Thank you for your help....In some languages I've used, you have to initialize everything because a variable's value is whatever was leftover in that memory space from the last time the memory was used.

Grub

[tst]

You can trust that you won't have junk, because LV takes care of the memory handling. The fact that USRs hold their data even when the VI is closed can be used to move data. If you have a non-reenrant VI with a USR you can call it from several places in your code and you are guranteed not to have race conditions because the calls are serialized. Once the VI was called from one place, all other calls will have to wait until the first VI releases the VI. This is called a LV2 style global.

You should note that the value will be held as long as the VI is in memory (it is only released when you close the VI calling it).

[Grub]

I just started using LV2 style globals (functional globals), and I must say, I find them much better in many ways than locals or globals (heavy RT user).  However, I didn't realize that the calls to LV2 Gobals were serialized....that opens up some possibilites I hadn't thought of before...thanks for the info!!!

[tst]

In RT, you should consider the right click option Skip subroutine call when busy. It may not be useful for LV2 globals, but if you have a VI that's called from several places, you can check that option to skip the VIs execution if it has already been called from another location.

BTW, the calls are serialized (that's the meaning of a non-reentrant VI), but you don't have any control over the order (except maybe threads of higher priority might get to run the VI first, I'm not sure).

Another option you may want to consider for globals is single element queues. Whenever you want to manipulate the global, you start by removing the element from the queue. This causes all other places calling the queue to wait (infinite timeout) until you put the element back into the queue, thus locking the global. I didn't benchmark it, but some benchmarks showed this to be about 6 times faster than LV2 globals.

[Grub]

I'm not sure what you mean by 'manipulate the global' by dequeing and element.  THe globals I work with usually have arrays in them.  Can you deque and array?

[tst]

I don't remember trying it off hand, but I don't see why you shouldn't be able to use an array as the data type for a queue. Then, assuming your entire array is the global, you simply dequeue it. Try it.

If you're not using the entire array as the global, you will have to explain how you are using it.

[Grub]

I tried this method and it works great...no more race conditions or data swapping from concurrent calls to the same subvi.  Thanks for the tip....

Grub