Leaderboard

This bug has been submitted to NI and confirmed. bug number 1289111

Dr. Powell pretty much gave my answer (stated more eloquently ). It's something to look out for when branching wires... by-value data is now a copy, while by-reference still refers to the same thing. Be aware of that when you start mixing by-value and by-reference inside class member data.

It's the inconsistent state that is the problem, where the by-value bit is inconsistent after the by-ref bit is changed in parallel. That doesn't always happen; sometimes either the value or the reference bit never changes. But one needs to be aware of this issue.

Hello. I haven't gone through the links provided in the opening post. However, it appears that Darren's recommendations pertain to the concept of (class or object) immutability - the general idea being that, once an object is created, its identity must be unique in your application domain. Note, however, this does not mean all class data members are constant - just the crucial attributes that 'define' the object. For example, a human being continuously evolves since inception. However, certain traits remain immutable, depending on the domain of reference: Biologically - DNA; Government - government issued ID#, etc. In my case, I am happy saving certain class data members without references, because I know those don't get overwritten once the object is created. E.g. 'id' as string - gets assigned when object is instantiated. All others are saved via references. My general heartburn vis-a-vis references, is the worry of how to group the data members for referencing. One DVR for all class members, though easy to implement, has greater chance of causing deadlocks. Although those ought to be caught with adequate unit testing. Of course, making all data members references ensures a consistency in implementation; as opposed to a mix of by-ref and by-val data members. The Actor Framework is neat in this context - when a launch actor is invoked, the output is actually a reference to the actor's unique 'mailbox'. Therefore, regardless of the number of wiring branches one invokes on that output; all 'messages' go back to the launched actor. IMHO, there is no need to save class member data as references in such frameworks, as long as the actor's internal logic is implemented without risk of race conditions.