Actor Principles, Complexity and Class Count

[Daklu]

jlokanis wrote:

I am really trying to reduce complexity and message class count here. 

Soooo... not to be flippant, but you do realize these may be opposing goals in your system, right? 

And the most effective way to reduce message class count is to switch from command pattern messaging to name data messaging.

AQ/Casey,

He's using a custom actors with his own messaging system; I don't think his actors have a "Pre Launch Init."

[AristosQueue (NI)]

Daklu wrote:

He's using a custom actors with his own messaging system; I don't think his actors have a "Pre Launch Init."

He may want to add one then. AF didn't have it originally. It was added to address exactly these concerns.

[CaseyLamers1]

Thanks,

I actually use the "High Priority" for that one method that I want to occur first. I understand that other messages "could" be sent to the particular actor. I have some sequencing of things for my system start-up that is based on replies from nested actors to manage/prevent race conditions.

I think I may want to move those to Pre Launch Init though. The reason they are in actor core is because I originally had some methods directly called (not messages) prior to actor core, but then when I had some hardware issues I wouldn't capture the error in my error logging. So I switched to messages and left them in Actor Core.

Casey

[jlokanis]

Daklu wrote:

And the most effective way to reduce message class count is to switch from command pattern messaging to name data messaging.

Life is a series of compromises!  I am not ready to throw in the towel on command pattern yet.

Daklu wrote:

He's using a custom actors with his own messaging system; I don't think his actors have a "Pre Launch Init."

Yup.  But I could add it.  I have been experiementing with different ways to startup an actor.  It would not be the first thing I stole from AF.

[mike-o-tronic]

AristosQueue wrote:

jlokanis wrote:

(still need to work out error handing in this case).

If you do it in Pre-Launch Init.vi, if you return an error from that function, the actor will never launch in the first place and the caller will get an error coming out of Launch Actor.vi. That's the easiest place to bottleneck initialization.

But you need to be careful where to call the Launch Actor.vi, since it will be blocked until the Pre-Launch Init.vi ergo the initialization is completed. And you couldn't interrupt in between the initialization steps. I'd rather go with the self-messaging from Pre-Launch Init.vi solution.

[mike-o-tronic]

One more thing...

Daklu wrote:

First, I need to point out the presentation I gave at the CLA Summit (and at last year's NI Week) is titled "Fundamentals of Actor Oriented Programming."  It's intended to introduce people to actor oriented programming using concepts that are familiar to QSM/QMH programmers.  Unfortunately there isn't enough time to dig into too many nitty gritty details like you are asking about.

Is this presentation available somewhere? I looked through the NIWeek Groups, but couldn't find it. And since you mention QSM programmers here...

Jed394 wrote:

There seems to be a debate about giving any actor(no mater what framework) the ability to message itself and put commands on its own queue.

Daklu wrote:

I don't know if "debate" is the right word. I advise against it because I don't think it scales well in practice, but in theroy it can work fine. In small doses it can be simpler than the alternatives. The danger is in not refactoring away from it soon enough.

(And to clarify, it's really about having a message handling loop send messages to itself. Helper loops sending messages to the MHL can be considered "an actor sending messages to itself," and that is fine.)

What are your thoughts about implenting QSM in an Actor? You think this is a case where it would be fine for the MHL message itself? I used the AF a few times to create QSMs, since MHL basically gives all the structure needed. I mean I just need to look at figure 1 and 2 of https://decibel.ni.com/content/docs/DOC-32964 and I'd really need to force myself not to use AF for implementing that

[AristosQueue (NI)]

mike-o-tronic wrote:

What are your thoughts about implenting QSM in an Actor?

We created the AF quite literally by starting with a QSM and slowly replacing pieces to retain the exact same functionality but with a different syntax that was more flexible/less error prone. For me, an AF Actor *is* a QSM -- they are semantically equivalent. I've debated this back and forth with Daklu and David in the past and know that they see a difference between the two. But for me, asking whether you should/could implement a QSM in an Actor is a hard question to answer since my answer is, "What else could you do other than a QSM?" The actor object is the state, there's a queue, and you post messages to make it do stuff.

[Daklu]

mike-o-tronic wrote:

Is this presentation available somewhere?

Last year's NI-Week presentation is available if you follow the link here.  I think the one I gave at the Summit earlier this month is better though.

NI recorded all the presentations at the CLA Summit.  I don't know if they will publish them for the community at large.  Mark Balla also recorded the sessions.  I'd keep an eye on LAVA for an announcement.  (Maybe this thread?)

[Daklu]

mike-o-tronic wrote:

What are your thoughts about implenting QSM in an Actor? You think this is a case where it would be fine for the MHL message itself? I used the AF a few times to create QSMs, since MHL basically gives all the structure needed. I mean I just need to look at figure 1 and 2 of https://decibel.ni.com/content/docs/DOC-32964 and I'd really need to force myself not to use AF for implementing that

It all depends on how you define "QSM."  AQ defines a QSM as the commonly seen construct of a while loop, a case structure, and a queue.  I claim that's not how the community at large defines it, and when people say "QSM" they are also talking about all the things they typically do with the while loop/case structure/queue construct.  (Like macros, enqueuing priority messages in front, having the loop enqueue messages to itself, etc.)

If your definition of QSM matches Stephen's, then yes, you can implement a QSM in the MHL.  In fact, a QSM is probably the simplest implementation of a MHL.  If your definition of QSM is closer to mine, then my stock response is, "Don't do it."  But if you put my feet to the fire I'll say "It is dangerous, very error prone, and creates unnecessary complexity.  It can be done successfully but it does not scale well.  Use it as a technique of last resort, and refactor away from it as soon as possible."

As for the QSM-PC document in the link you posted... it is very well written and I have not read through the entire thing, but I disagree with almost everything it endorses.  Reading through it was painful, like listening to fingernails on a chalkboard.

Looking at figures 2 and 3 confirm what is true about almost every QSM I have seen--potential race conditions abound.  Five different loops (the event loop, the three sub vis, and the consumer loop itself) have the ability to enqueue "states" for the consumer loop, yet figure 3 shows a macro implemented in "STATE 2."  (We'll ignore the obvious bug of STATE 2 enqueuing itself in the implementation.)  We can assume states 2, 3, and 4 must be executed in order, but we have no way to guarantee the four other loops won't enqueue a different message in between those 3 messages.  Will it matter?  I dunno... the only way to figure it out is via code inspection.

You said, "I'd really need to force myself not to use AF for implementing that."  That's exactly why I continue to assert QSM != Actor MHL.  The biggest problem with the QSM-PC example explained in the document isn't in the implementation; the problem is in the design.  (Or more specifically, in the design created from the incorrect QSM-thinking belief that the owning loop controls the state of the queue.)  It doesn't matter if you implement that design using the AF, or Agile Actors, or your own actor implementation.  You'll still have nearly all of the same problems as the original implementation because the design (or designer) failed to recognize the fundamental truths of concurrency, one of which is, "You (meaning the loop) have no control over the execution timing of any other loop."

[Daklu]

AristosQueue wrote:

"What else could you do other than a QSM?"

What else could you do?  There are all sorts of possible variations in the message transport.  How about message transport that acts like a stack instead of a queue?  (Admittedly limited in practical usefulness, but perhaps there are use cases for it?)  Or how about a tag (last value) type of transport?  Or how about a transport that permits multiple paths to allow robustness against broken communication paths?  (Think internet.)  If multiple paths are allowed then the whole concept of maintaining message order (i.e. queues) gets thrown out the window.

I agree queues (both the primitive construct and the general FIFO behavior) provide the greatest amount of convenience for message transports while requiring the least amount of overhead, but it's far from the only solution.