Replacing Functional Global Instrument Drivers

[LVB]

On-Demand Communication With Legacy Code and Actors

I had a few questions regarding best practices when integrating Actors with legacy code (non-actors).  Consider the following "use case" that replaces a Functional Global Instrument Driver:

• The Actor-to-Callee queue cannot be used due to the existing architecture
• The Actor is a digital input driver
• The Actor continuously logs the state of all digital IO every "n" seconds
• We want to implement a mechanism to read the "current value" of a digital input line on demand.

For methods in the legacy application that request data from the Actor, it seems appropriate to use Synchronous Messaging since we want the "current value".  Sending synchronous messages from a non-actor should have no risk of deadlock because there is no "callee Send Queue".  However, this will quickly become a problem when another actor needs to communicate with the digital input driver.  This could also be a problem risking deadlock if two digital input Actors wanted to read the "current state" of each other.

• What are your suggestions for "best practices" in this situation?
• Could this be designed simply without Synchronous Messaging?
  • It seems that a "request ID" could be associated to each "read request", but this seems like it may be over-complicated
    

Using the Actor Framework in LabVIEW Document

On a related topic, the "Using the Actor Framework 3.0 in LabVIEW.pdf" states "You do not have to override Do Core.vi if the only feedback your message requires is acknowledgement of receipt."  The latest version of the framework requires override on the "Do Core.vi".

Thanks,

Brian

[drjdpowell]

Why not use syncronous messaging from your API (that substitutes for the older Functional-Global API) but asynchronous messaging from other actors?  I notice that the Actor Framwork has a "Reply Message" that only supports synchronous use through "Send Message and Wait For Response.vi", but it could easily be extended with an extra "Send Message (with Async Response).vi".  This later VI would have a input terminal for the "Send-to-Self" queue of the sending actor, which would be attached to the message.  Other actors could use this VI with Reply Messages. 

Another possibility is to use a dedicated connection between your actor and API, such as a notifier containig the latest digital IO; then use regular async messages between actors.

-- James

Note: had a look at it, and it seems that "Reply Message" class would have to be modified to use a "Send Queue" rather than a primative queue for replies, so it would require a little more extensive change to the Actor Framework than just adding an extra method.  So let me make the formal suggestion that "Reply Messages" be made to support asynchronous replies in addition to synchronous. 

[AristosQueue (NI)]

drjdpowell wrote:

So let me make the formal suggestion that "Reply Messages" be made to support asynchronous replies in addition to synchronous. 

Before deciding whether this is functionality that belongs on Reply Msg or on a different class, let's lay out what this class would need to do. I'm going to call this hypothetical class Async Msg.lvclass. In order to be truly asynch, it would do the following:

1. The sending actor creates Asynch Msg and embeds within Asynch Msg the data to be sent to the receiving actor.
2. Sending actor sends the message to nested actor: The Send function puts the caller actor's Send queue into the message, puts the message into the queue and immediately returns.
3. Receiving actor receives the message and calls Do.vi.
4. Inside Asynch Msg:Do.vi, the message calls whatever method(s) it is designed to call on the receiving actor, and then it takes the outputs of the method(s), packages them into a new message and sends the new message back along the Send queue that was saved inside the Asynch Msg.

That's essentially what any message class that wants to send a reply does... the only commonality is the inclusion of the sending actor's Send Queue as part of the Send operation. Putting ancestor behavior into Send is tricky because every message class has its own Send.vi with its own specific parameters.

We don't want Reply Msg to use an actor's normal Send queue for the reply because the actor isn't going to be checking the normal queue because it is halted waiting on a synchronous reply, so I don't think you can merge this functionality.

My thought is the best you could do for a common Asynch Msg class is create a class that has the Send Queue in the private data and exposes a Read and Write VI for that data member, but you couldn't enforce that getting filled in because the Send VI isn't capable of being dynamic dispatch because of the conpane differences issue. I don't know how valuable that would be in practice.

I suggest the better behavior *might be* (just thinking outloud here, nothing definative) to just put the Send queue in as part of the message and let the method on the receiving actor take care of sending whatever message it wants, and do that on a message-by-message basis, since it's going to have to have specific code for populating the reply message anyway.

And, as with Reply Msg, be careful with this approach as it veers dangerously close to an actor saying, "Hey, other actor, tell me this fact" and then the other actor replying, which in most cases I've investigated is not as good as just having the other actor announce from time to time "my state has changed".

[drjdpowell]

AristosQueue wrote:

Before deciding whether this is functionality that belongs on Reply Msg or on a different class, let's lay out what this class would need to do...

Didn't quite follow all that, so instead of replying, here's a quick alteration of the Reply Msg class (untested).  It uses a Send Queue in place of the simple queue, allowing an additional method to be added: "Send Message with Async Response".

And, as with Reply Msg, be careful with this approach as it veers dangerously close to an actor saying, "Hey, other actor, tell me this fact" and then the other actor replying, which in most cases I've investigated is not as good as just having the other actor announce from time to time "my state has changed".

Yes, and with my own messaging/actor library, although I have "Replies", I mostly use publishing of current state.  However, the OP wants to use an actor both called from a non-actor FG-style interface, in addition to another actor.  Thus a duel-mode asyn/sync message might help. 

-- James

Note added later:

AristosQueue wrote:

Putting ancestor behavior into Send is tricky because every message class has its own Send.vi with its own specific parameters.

That's only if one makes methods that combine the message writing with the sending.  Children of "Alternate Reply Msg" need only contain a "Write" method, then they can use either of the two sending methods (sync or async) in the parent class.  They don't need a "Send" method.   At least I couldn't see a reason why; is there a reason you use message-specific "Send" methods, rather than "Write" methods with generic send methods?

I've updated the attached zip project with an example child class with a write method.

Message was edited by: drjdpowell

[AristosQueue (NI)]

Ok, I can see the value in the class, but I think it's still better as a separate class from the Reply Msg class. My reasoning for that is that synchronous Reply Msgs are dangerous if used on both sides of a communication link, and I would like to be able to search a hierarchy for all uses of that class or its children in the event that I do have a deadlock to see if use of those classes is the source of the problem. It might even be the sort of thing that we could write a tool not unlike VI Analyzer to detect. Since this asynch message is safe from deadlock, I'd suggest we add this as a separate class.

Thoughts?

[drjdpowell]

> Thoughts?

Well, thought one is that I don't think one can prevent someone creating an out-of-framework subVI that sends an Async Reply Msg synchronously (because none of the required methods for creating a temporary send/receive queue are protected/private). 

Thought two is, why would one send a reply message to one's caller?  If the callee is a component (hopefully a reusable one) of a system, it shouldn't "know" anything about it's caller, and shouldn't be sending it commands that require a response.  It shouldn't be sending it commands at all.  It should just be replying to the caller's messages and sending out informative messages that require no response. 

I don't know how to enforce that in the Actor Framework, though.  In my home-grown actor design, the caller/callee communication link is asymmetric; callees don't have their caller's message queue and thus can't actually send a reply message (despite the fact that "reply" functionality is built into my parent "MSG" class).  They reply to the caller's commands, or publish informative messages that the caller can subscribe to.  But the actor framework uses a symmetric bi-directional communication link, so I can't see a way to restrict/discourage callee's sending reply messages to their caller. 

-- James

BTW, if I was dealing with the problem of the OP in my own system, I actually wouldn't use reply messages to read the digital IO.   The "Digital IO Actor" would publish the latest values.  The FG replacement code would create notifiers and register them to receive the updated digital IO, then the subVI that gets the latest values would just read the notifiers.  Totally asynchronous.  Other Actors would instead register their own Message Queues.  But that's only doable because I use multiple child "Messenger" classes to plug in different communication methods as needed (queue, user event, notifier, TCP server/client).

[AristosQueue (NI)]

> BTW, if I was dealing with the problem of the OP in my own system, I actually

> wouldn't use reply messages to read the digital IO.   The "Digital IO Actor" would publish the latest values.

That would be my solution as well, though I do it by registering different message types instead of different communication methods.

> Thought two is, why would one send a reply message to one's caller?

An asynch reply probably not. But a synchronous reply, I can see some programmer deciding that was a good idea because then they can just hold the nested actor and wait for data. But the more interesting case is not the caller. An application might choose to establish direct communication between two sibling (or other more estranged) actors, and in that case, reply messages become an issue.

[drjdpowell]

AristosQueue wrote:

But a synchronous reply, I can see some programmer deciding that was a good idea because then they can just hold the nested actor and wait for data.

That's not a good idea.  All actors should endeavor to read incoming messages promptly; they should not be written to deliberately stop listening to the incoming queue.  Personally, I've only used synchronous messaging for either non-actors, top-level actors, or "I know this will only take a fraction of a second, and it's easier and clearer to write it this way." 

AristosQueue wrote:

But the more interesting case is not the caller. An application might choose to establish direct communication between two sibling (or other more estranged) actors, and in that case, reply messages become an issue.

But again, does this communication need to be symmetric?  Could not only one of the two siblings be give then queue of the other, and then act in the same way as a caller.  I've written a UI Actor that was passed the queue of the Actor it was a UI for, but the other actor was not given the queue of the UI; instead, it just published state information and replied to the UI's commands.  Are there cases where two sibling actors need full "Hey, you, do this for me right now!" control over each other?

[AristosQueue (NI)]

No *good* cases. That's why I want the Reply Msg class to remain analyzable -- so we can highlight for people when they've got a bad design.

[AristosQueue (NI)]

I just realized... this async message we're talking about... why isn't that just the Self-Addressed message that is already part of the AF palettes?