Network Published Shared Variable Array Handling

[NI-MarkN]

Currently, for an array variable, changing an element requires the developer to read the array, update the element and write the array out. Whilst this is fine for simple cases with not sophisticated data flows, it becomes very cumbersome for cases when parallel processing is introduced. For instance, multiple loops updating an array of status flags.

At present, if two loops (which may be in different Vis) both execute a read-update-write operation on a global shared variable, data can be lost if the operations happen at similar times. Consider the following example: 

Looking at the image above, let's imagine "array1" consists of two elements with values F and T respectively. Then the operation would happen as follows:

Step Number	Action taken	Array values
1.	Read "array1"	F and T
2.	Read "array1"	F and T
3.	Update "array1" element 0 to T	T and T
4.	Update "array1" element 1 to F	F and F
5.	Write to "array1"	T and T
6.	Write to "array1"	F and F

Hence all the data written by “Loop A” is lost. Putting user-defined locking using shared variables around the operations does not seem to work, presumably due to update rate of the locking variables.

What would be helpful to overcome these race conditions is to replicate the functionality present in other languages to do operations like a[3]=4 or printf(“%lf”,a[4]). In these cases, an atomic operation is performed to get or set the value in the defined memory location. The addition of this functionality to shared variables would be extremely powerful.

An example of such functionality could look something like this:

[AristosQueue (NI)]

@Steen: I knew it was a network enabled SV... I didn't pick up on the fact that he had multiple clients writing to it at the same time. Ok, yeah, the subVI is the wrong tool in that case... if you are going to have each remote machine making changes to the variable.

@NI-MarkN Can you set up some sort of buffered communications to the machine that hosts that data and instead of trying to do operations on the remote machines, instead tell the central machine "make this change to the data"? If so, the subVI then becomes sufficient protection. You would only ever read the variable on remote machines ... all the read/modify/write work would be done by one machine.

[SteenSchmidt]

Ok, two things confuse this question then:

Are we talking about network published shared variables (which the OP illustrates with his images), or just globals on one target (which the OP seems to ask in his text)?

The former can most easily (if only at all) be done on the SVE, as that is the single arbiter of the network published shared variable. Are we on the other hand talking about encapsulating access to a global (of any technology) on one target, this can be done by many means all of which involve a non-reentrant subVI as you (and RavensFan) describe. The complixity of that subVI is then only dictated by the requirements to performance and API.

/Steen

[SteenSchmidt]

One limitation of a network shared variable is that even though your application may have only one reader and/or writer which would enable you to do some sort of simpler locking than the general case requires, you can't stop someone else from suddenly accessing the same variable from another application. Therefore you must always treat network shared variables as having concurrent r/w.

/Steen

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.