LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why should Shared Variables be serialized?

The Best Practices (Real-Time) Help for Shared Variables in LabVIEW (2012) says "Improve performance and prevent race conditions by executing shared variable accessors serially", and then gives some examples with further comments about not accessing them in parallel.

 

Can someone explain why performance is improved and race conditions avoided this way?  I'm assuming, of course, that each of the Shared Variables you access is unique (clearly trying to write to the same variable twice is better done in serial, as it is "deterministic" -- when the code finishes, the S.V. will have the second (last entered) value).

 

I've noticed these snaky error lines used to serialize several Shared Variables, and never understood "Why".

 

Bob Schor

0 Kudos
Message 1 of 2
(2,239 Views)

My guess is how the underlying TCP communication is working, but since that is all black magic to us, we can only guess. You will most likely have to wait for an NI employee to comment on that aspect. Remember, also, shared variables can be written and read both locally and from a remote PC, so in theory you could introduce race conditions within your application itself if you are both writing to and reading from a shared variable. Essentially, causing the same issues as you would with local variables.

 

That said, I prefer to write my own network communication because then I have complete control over all of this. This quote is one of my favorites from Ben Rayner with regards to shared variables "lets take the danger of globals and allow the devlopment of race conditions across platforms"

Message 2 of 2
(2,220 Views)