From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
GDS(Goop Development Suite)
By reference vs. By value
I didn't think this would turn into such hot discussion.! 
However, I get that, though people start off with by-value, as the projects gets large-scale then people naturally looks for by-reference changes in it. Thanks AQ for the caution during that case
AristosQueue wrote:
mutual exclusion protection offered by references as a last-resort shield
Ajayvignesh_MV wrote:
However, I get that, though people start off with by-value, as the projects gets large-scale then people naturally looks for by-reference changes in it. Thanks AQ for the caution during that case
I find that "actors"**, or whatever one calls an asynchronous loop interacting with messages, handles scale, rather than by-ref objects. Of course, an actor is basically a kind of by-ref object. An actor is active (rather than passive like a DVR), so it can do things like publish information rather require polling. For common resources I tend to have a by-value "driver" object, contained in one "resource actor", with the actor's reference being shared.
** "actors" in general, rather than Actor Framework "Actors" specifically.
drjdpowell wrote:
I find that "actors"**, or whatever one calls an asynchronous loop interacting with messages, handles scale, rather than by-ref objects. Of course, an actor is basically a kind of by-ref object. An actor is active (rather than passive like a DVR), so it can do things like publish information rather require polling. For common resources I tend to have a by-value "driver" object, contained in one "resource actor", with the actor's reference being shared.
** "actors" in general, rather than Actor Framework "Actors" specifically.
drjdpowell,
That's a completely new view and it's taking time for me to digest it (I mean actor here). May be because, I have been using the polling mechanism (using Queued State machine to share messages between the asynchronous loops) so far and I'm still not finding actors in my feature projects. I think, you're inherent to the same caution of AQ while using by-reference, where you have the actor which protects itself during mutex operations. Is that correct?
DQMH is available from Delacor.
AQ & drjdpowell, please correct me if I'm wrong here. I have once read about DQMH and it's primarily based out of user events (with data) in LabVIEW. The user events which is generated by other asynchronous loop, works like an actor here. Isn't it?
The objections you raise are *exactly* the ones raised by procedural programmers when first confronting OO.
AQ,
I find the similar kind of objections like AF looks clumsy with lot of messages in my project blah blah blah.. though I haven't realistically used it in any project. I don't want to risk taking it in my project unless I am sure confident about completing the project with actors. How could that gap between such objection and acceptance for the people could be closed? Do you have any suggestion like looking at some reference proejcts?
Ajayvignesh_MV wrote:
AQ & drjdpowell, please correct me if I'm wrong here. I have once read about DQMH and it's primarily based out of user events (with data) in LabVIEW. The user events which is generated by other asynchronous loop, works like an actor here. Isn't it?
The message handler itself is an Actor. Terminology sometimes gets in the way of these discussions.
Whether to use User Events or Queues for message transport to the QMH/Actor/Module/etc is a whole other discussion with very good arguments for each side.
