How does AF handle continuous execution of some action?

[Daklu]

@LVB

I don't think creating a manager and processor actor directly solves the problem posed by GotRobotFriends. It is a useful technique (I use it frequently) for reducing the number of messages a critical actor needs to respond to but it doesn't make the processing actor "continuous."

Actors are inherently reactive. In basic single-loop implementations, an actor does nothing unless it receives a message. When it receives the message, the actor processes the message and goes back to doing nothing until the next message arrives. Introducing a managing actor doesn't change that fact about the processing actor.

The simple work around to making an actor "continuous enough" is to use a metronome or self-addressed messages so the message handler executes often enough to simulate a continuous processes. Neither option is particularly good if you need an actor to be "truly continuous" in the sense that the loop will execute as quickly as possible without interruption until it finishes or is instructed to stop.

A metronome runs into the message throughput problem. It would have be tuned to send messages at exactly the same rate at which the processing loop consumes them at any given time. Send them too slowly and time is lost waiting for the message. Send them too quickly and the queue length grows, which in turn increases the amount of time it takes for the processing actor to respond to a sent message.

Self-addressed messages avoid the message synchronization problem by having, for example, the SampleData message handler send the actor another SampleData message just prior to exiting. However, they have other effects that make them less desirable solutions for some people. (Such as using a queue to create "pseudostates" instead of explicitly coding behavioral states, often leading to the need to directly manage queue contents.)

The reactive nature of actors doesn't easily lend itself to truly continuous processes. If you want an actor to really be continuous you have to build that functionality into the actor itself by, as Elijah mentioned, implementing the continuous process as a parallel loop in Actor Core. (Both Elijah's example and the DVR example in the link James posted illustrate the same idea, albeit for different purposes and with different implementations.) Note the continuous loop is not an actor in itself. It is a subcomponent of the actor. Making the continuous process an actor just pushes the problem down one level.

Actor oriented programming does not--imo--mean non-actor parallel loops are no longer needed. Not all parallelism in LV is best implemented as an actor.

[komorbela]

I have made a benchmark.

I created a base actor class that has all the non-actor based functionality. It only increments a counter and does a Sqrt and square operation on a DBL N times to simulate a "heavy load". It checks for stop condition and pops up the elapsed time if stopped.

This "Iteration" is tested in a while loop, and in an actor as a self addressed message.

You can look at my results in this small screen rec.

So the lightest loop, that had only one I32 increment in one iteration ran about 10 times slower, but it is still about 50 kHz.

The messaging has an overhead, but as soon as the loop actualy does something that last for at least a 100 ns, it will become negligible. The overhead on my PC is about 19 ns in one loop.

[AristosQueue (NI)]

I'm still making my way through the backlog of this thread -- just got done with NI Week and probably too tired to read more today. Just got to Fabiola's post, and I just wanted to chime in that as far as I know, DVRs are universally better than SEQs except for the ability to have named queues. But in terms of compiler efficiency, ease of use, and avoidance of the Dining Philosophers deadlock problem, prefer DVRs over SEQs. And since you shouldn't be using a variable between actors, the loss of naming should not be an issue (i.e., the one refnum is good enough for all uses within a given actor and no other actor should be using the DVR).

<pause>

I have just decided that I'm just going to skip reading the rest of the thread today. Anything I do is likely to be incoherent from lack of sleep. 🙂 Thanks to everyone who came to town and helped spread the excitement about the Actor Framework. It was a great week.

[AristosQueue (NI)]

Oh, wait... one more note... for GotRobotFriends... you want a process to run continuously but you don't want it to be interrupted by other messages... just create a metronome to send a message to itself and then don't send any other messages to it other than Stop (or other "change what you're doing messages"). Since actors can *only* be messaged from their caller, it's easy enough to nest one actor inside another and make the inner actor completely unaware of the rest of the world.

Alternative to this is the Timed Loop solution that is in the shipping example for the evaporative cooler in LV 2012. That avoids messaging itself entirely.