Proposing a change to Launch Actor.vi: No more required caller input?

[AristosQueue (NI)]

OH THE IRONY. Literal irony. Literally.

I made a post this morning replying to drjdpowell explaining why ordered communciation is key to the AF and why I support calling them "queues". I got a message that the post was awaiting moderator approval. I then wrote a second post, which you can already see, replying to Daklu about the name for top-level actors. That one was approved automatically. My first post was all about how communication becomes harder to understand when messages from the same sender arrive out of order. When moderators approve my earlier post, we'll see whether it appears before or after these two. 😉

[Daklu]

AristosQueue wrote:

Thoughts?

I think your assessment of the two names is spot on.  Personally I favor #2.  It flows off the tongue more easily and strengthens the idea of a tree, which is a central principle of the AF.

AristosQueue wrote:

You make a good argument against calling this a "top-level actor", even though you made the argument for the wrong reasons. 😉

Heh... that I messed up on the details doesn't surprise me in the least, but I'm glad you understood the core of my objection--even if I didn't. 

AristosQueue wrote:

The setting of AutoDispose does not matter. Any VI executed through the Run VI method is running top-level -- which means refnums inside of it have the lifetime of the run VI, not the caller. Also, aborting the caller will not abort the VI (except as a side-effect of the last reference being released, which is why such a VI needs to open its own refnum if the caller uses AutoDisposeRef=False). Contrast this with the Call By Reference node -- any refnum opened inside the called VI will have a lifetime tied to the caller and aborting the caller will abort the called VI *even if* the called VI has opened a reference to itself.

There's a reason I got the details wrong... this stuff is confusing.  If a vi will abort when (a) the vi owning its reference is aborted, or (b) the last reference to it is released, what mechanism does LV use to prevent a vi from aborting as soon as I click the run button?  Does the vi open a reference to itself behind the scenes?  Does the run-time engine open a reference to it?  Something else?  Is the same mechanism used in both the dev environment and in an executable?

[SteenSchmidt]

Quite funny that in my mailbox this message was tagged as from Matt_McLaughlin, while it's in reality from you Stephen. That's not even out-of-order, that's a shortcut the long way through another reality .

It was and is a conscious decision for the AF. Having a lossy connection between actors is fine; having messages arrive out of order (from the relative postion of the sender) is not.

But that is a conscious constraint of the Actor Framework in LabVIEW, right? If I understand the Actor design pattern (used universally since the seventies) properly, an actor is indifferent to message arrival order as the actor is in power to act on the received messages in the order it sees fit anyway, or not to act at all. And if you can act on messages in any order, that's indistinguishable from messages arriving in any order. It is the responsibility of the message to request any order to its own execution, or to reference another message correctly (for instance in the "undo something else" situation). A plain vanilla actor design pattern isn't a good choice for sequential execution.

I agree that you do not care *how* it gets there. I believe you do (despite protestations) care about *when*. After studying many of these applications and listening to many of you describe the functionality of your applications, I began to realize that the vast majority relied upon the ordering unconsciously, even when they consciously said they were aware that events might happen out of order.
...
If a user types some text and then clicks the OK button, they'd be mightily confused if the text that was committed was an empty string because the effect of the Click registered before the effect of the keystrokes.
...

This need for ordered communication is true in every application I observed. In *theory* an actor *can* be designed such that the order of messages *from the same sender* does not matter. In practice, that never happens in my observation, and I believe my observation has been long enough to relegate the possibility to a statistical anomaly.

I must say that I haven't observed ordered vs. prioritized execution so much one and never the other as you describe it. Sure, there are many situations where you desire ordered execution, and then you'd use a queue. If not for anything else, then for relieving the messages of the burden of a sequence number. You get that for free with a queue.

Regarding the submit action when you enter text into a UI; There are two steps to this:

1) Text entered into a UI does not happen with an actor design pattern, but rather through some sequencing logic (a single interrupt, a single UI thread or something similar that guarentees FIFO). If you automate UI input (char by char) with a concurrent mechanism you're bound to get into trouble.

2) Submitting less than the complete text when you hit OK isn't really a racing condition either, as you'd transmit a "OK" message with all the text as payload data. And 1) above guaranteed us that all the text entry was processed before it was possible to process OK.

Back to out-of-order execution. Many real-world examples exist that would make perfectly sense to implement with actors that could decide the processing order of received messages (and thus could be immune to out-of-order reception as well). If referencing other messages is the sole responsibility of the message itself, then the actor is immune to out-of-order reception. A real-world example of out-of-order execution is a scheduler for instance. Messages can pre-empt other messages due to priority. Or the execution of a request could be halted until a resource became ready, while other messages could be executed freely in the meantime. Or the case where an actor spawns new actors to handle each message - then there would be no guarantee of the order in which these actors returned with their loot. The latter could be a parts picker being ordered to get such and such parts, and then the master parts picker sends small robots into the storage facility to fetch each their part, and when they all have returned you're done. Each little robot might encounter and overcome their own small problems, but will eventually return. The order in which they return could be of no importance. So real-world examples of out-of-order execution are abundant (but you know that, so I might have misunderstood you?).

/Steen

[wirebirdlabs]

drjdpowell wrote:

And personally, I think of messages being sent to an address.

That's legit, I tend to agree -- on the other hand, I think that depending on your framework, the name of this "Enqueuer" or "Mailbox" or "Actor Reference" or "Address" is sensitive to semantics of your framework -- namely, describing the API of your actor -- what does its surface area to the world appear to be? In AF, an Enqueuer seems like a good name -- for RESTful web services, a URI (address) makes sense. "Mailbox" might be considered a leaky abstraction -- perhaps we define that a "mailbox" should be privately scoped to the owning actor.

I think of an Address as an identifier that can be dereferenced to one Actor (or, [0,N] actors, in frameworks which allow multicasting a message) -- whereas a Mailbox is more complex, more like an active object (or, it could even be an actor itself, proxying messages to the business-logic-actor or acting as a load balancer between many identical actor clones). A Mailbox has an Address as a field, and perhaps that's what should be exposed over the actor's API.

Thought, Message Enqueuer.lvclass still makes good sense in the context of AF, where the "address" is the refnum of the Enqueuer itself. (Sure, the Message Enqueuer is by-val and does not have a refnum per se in AF -- but for all intents and purposes, our mental model can consider this Enqueuer a by-ref object.)

I'm not adding to this discussion, so much as thinking aloud, but would at least like to encourage further conversation on terminology -- once you nail the terminology, the semantics fall into place. If I could pick one Programming Superpower, it would be choosing good names for things.

[MattP]

Daklu wrote:

There's a reason I got the details wrong... this stuff is confusing.  If a vi will abort when (a) the vi owning its reference is aborted, or (b) the last reference to it is released, what mechanism does LV use to prevent a vi from aborting as soon as I click the run button?  Does the vi open a reference to itself behind the scenes?  Does the run-time engine open a reference to it?  Something else?  Is the same mechanism used in both the dev environment and in an executable?

Article on topic (marginally useful): 

http://digital.ni.com/public.nsf/allkb/9B3742FFA1C9B1BD862576D700247720

Video linked in the article from LV R & D developer (one of the most coherent explanations I've seen):

http://www.eyesonvis.com/blog/Viewlets/VIRefs/eyesonvis_vireferences_viewlet_swf.html

[Todd_Lesher]

I like reading about all of the details. I also do not have anything to add to the conversation. I just want AF to be simple enough to not scare off a "traditional" LV programmer.

From this unsophisticated point of view:

1) An actor either has a caller, or it doesn't.

Most of my actors have a "launch.vi" that specifies required inputs. If an actor has standalone or simulation capabilities, launch.vi can recognize whether it's at the top of the call chain. In that case, launch.vi creates the MQP and waits on last ack from the dequeuer. (With transparency, a-la Staab's launch template I saw posted here, once.)

2) An actor receives messages

If the actor is stand-alone, messages usually come from button presses on the FP - or from time-delayed repeats.

3) An actor sends reports

The report objects get passed in to launch.vi. Makes stand-alone useful, too.

I guess what I'm saying is: I don't care what the datatypes and VIs are called (though "enqueuer" and "launch..." show up nicely in quick drop). I just want to be able to label things "caller", "doer", "message" and "report".

[David_Staab]

Todd_Lesher wrote:

I just want AF to be simple enough to not scare off a "traditional" LV programmer.

That'll take a lot more than a little API/nomenclature change...

[Daklu]

SteenSchmidt wrote:

It was and is a conscious decision for the AF. Having a lossy connection between actors is fine; having messages arrive out of order (from the relative postion of the sender) is not.

But that is a conscious constraint of the Actor Framework in LabVIEW, right? If I understand the Actor design pattern (used universally since the seventies) properly, an actor is indifferent to message arrival order as the actor is in power to act on the received messages in the order it sees fit anyway, or not to act at all. And if you can act on messages in any order, that's indistinguishable from messages arriving in any order.

This is incorrect.  Let's assume actor X sends MsgA and MsgB in that order to actor Y.

When processing messages out of order, Y receives MsgA, does nothing, then receives MsgB.  After receiving both messages Y chooses to process MsgB prior to MsgA.  When receiving messages out of order, Y receives MsgB, processes it, then receives MsgA and processes it.

On the surface they appear identical--MsgB was processed before MsgA.  The difference is in what Y knows when MsgB was processed.  In the first case, Y knew about the existence of MsgA.  In the second case it did not.  The knowledge of the existence of MsgA can, and often does, have a direct impact on how MsgB is processed.

-----

You are correct, however, that the Actor Model specifically says messages may arrive in any order, even messages from the same actor.  That is useful from a modelling perspective in certain types of system domains.  In the domains the AF is specifically targeting, that aspect of the model isn't particularly useful, and trying to adhere to it would create far more complexity than necessary. 

The Actor Model is only a model.  It's not possible to implement it without making decisions that either conflict with or fall outside of the scope of what the Actor Model defines.  Any implementation is going to have to balance ideological purity with real-world pragmatism.

[Todd_Lesher]

David Staab wrote:

Todd_Lesher wrote:

I just want AF to be simple enough to not scare off a "traditional" LV programmer.

That'll take a lot more than a little API/nomenclature change...

True. Sometimes, I put a small, non-critical piece of functionality in a very simple actor. For example, a debug-time monitor that just displays dynamic user events. Conditional disable. Sneaky.

[Daklu]

JackDunaway wrote:

...I think that depending on your framework, the name of this "Enqueuer" or "Mailbox" or "Actor Reference" or "Address" is sensitive to semantics of your framework

Bingo.  Good APIs make it easy for developers to construct a mental model of the various API components and how they interact with each other.  Choosing names that accurately convey the developer's mental model to users is an important aspect of design.

In the AF messages aren't sent to addresses; they are sent to actors.  In everyday language an address specifies a location, not an single person/actor.  An AF enqueuer specifies a single actor, not a location.  Thinking about it in terms of addresses adds a layer of indirection that doesn't exist in the AF (but which could exist in other actor-oriented frameworks.)