Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Actor Overload!

After learning about new techniques in LabVIEW/software development, I often find myself over-using the technique.  After the introduction of the Actor Framework, I am having a hard time using other design patterns.  Simple stand-alone modules with a lot of user interaction still lend well to the JKI State Machine.  If an application already has a design pattern in use, I stick with that pattern.  However, I find myself always selecting the Actor Framework for any new module that needs to communicate with other modules. 

I am interested in how others determine to use the Actor Framework.  When do you find it NOT appropriate to use an Actor?

CLA, CTA
Message 1 of 44
(16,115 Views)

Naturally someone would ask this question now. Of all times, it had to be now.

I'm up to my elbows in code and deadlines for the next couple of weeks, but I have a notebook and a whiteboard covered in things I do and don't like about AF. I want to share them as soon as possible...but I can't just yet.

Suffice it to say this: AF is not the right choice for many kinds of projects. If you're working on a small app or something with a lot of UIs to develop, I would look elsewhere for a communications framework. It also has out-of-the-box bugs in LVRT that require making a branch to repair, so I don't use it on RT targets either. However, if you're the architect in charge of multiple developers on a large project, AF provides lots of safeguards (in the form of type safety and limited access scope) to ensure they won't do anything incredibly stupid when you aren't watching.

0 Kudos
Message 2 of 44
(5,350 Views)

LVB wrote:

After learning about new techniques in LabVIEW/software development, I often find myself over-using the technique.

Yeah, I think that's pretty common when learning OOP.  I've done the same thing and I see comments from other people that lead me to believe they do it too.  It's not necessarily a bad thing... it helps you discover the limits of the particular technology or technique you're using.

LVB wrote:

I am interested in how others determine to use the Actor Framework.  When do you find it NOT appropriate to use an Actor?

Actor-oriented programming is a paradigm shift, much in the same way switching from traditional LV to LVOOP is a paradigm shift.  In fact, if you ask yourself "when do I find it not appropriate to use OOP?" you'll find the answers are very similar:

When should I consider NOT using actors (or LVOOP)

* When the people responsible for maintaining the code don't understand the technology.

* When the code's purpose doesn't justify spending extra time on implementation.  (Prototype code, etc.)

* When using it adds accidental or irrelevant complexity.  (Example code, etc.)

* When you need highly optimized code.  (Perhaps FPGA or RT code.)

In general actor-oriented programming can do everything previous multithreading patterns (QSM, etc.) can do, except it can do them better and safer.  When you decide your app needs a parallel thread, there's no reason not to use an actor.

0 Kudos
Message 3 of 44
(5,350 Views)

I am relatively new to AF (4 month or so), so my response is not based on long time experience. I just share my thoughts, hoping it helps .

I usually create the functional units of the system first. These are the so called "units", that have one specific well defined task. These are usually in the form of LVOOP. These could be used with or without AF.

At this point I analyze which units should run parallel, could run parallel and which ones depend on each other, so paralellization has no advantage.

The units(or items built from units) which really should run parallel are packed into an Actor by inheriting these units' Classes from Actor Class, creating a child Class of these modules and adding all the actor based functionality to this child, like special methods to be called by messages, methods that contain other Send message functions, etc.

After the Actors are defined, design the messages, and create those.

Create a controller architecture for the system that starts the Actors and manages messages.

If you need even a small bit of code to be run parallel and you are quite sure that it must be parallel, I suggest to create an actor for it.

However there are limitations regarding the number of Actors that a regular PC can manage. I just made a test with my (4GB, Win7, Intel i5 2400) development PC to launch and stops many instances of some actors continously. These actors had no functionality, Just created to see the how big the overhead is related to Actor creation. I could easily manage 1000 Actors, 3000 was on the limit (of my patience), but about 5000 things stared to slow down critically. Also interesting to note that after initialy launching and stopping the Actors, on the next iteration the launching process was faster. Probably the stopped actors left in memory are intelligently reused. In numbers:

Actors  (number):     500      1000     3000     5000

init time      (ms):     800      2200     14000   40000

relaunch     (ms):     550      1100      4000    7000

Used Mem (MB):     20         90        260      500

So, it means to me not to create automatically a bunch of Actors (for example to make your program take advantage of the 256 core CPUs of the future), but if I can keep the numbers of those below 500- 1000, I am fine.

Message 4 of 44
(5,350 Views)

I'll add the biggest "don't use case" that I see: Don't use the AF when your app just has one single process. For example, if you need to show a modal dialog to a user, do not create an actor to represent that dialog. If you need to have two windows open at the same time with the user working back and forth between them, sure make each one an Actor, but it's overkill to use AF for something that is a subroutine of a serial process.

Message 5 of 44
(5,350 Views)

Daklu, you have solid points about actor-oriented design (AOD), but the thread is more about the Actor Framework. There are (as you of course know) other tools that can be used to achieve AOD, and each of those has its own limitations and benefits.

Message 6 of 44
(5,350 Views)

DavidStaab wrote:

Suffice it to say this: AF is not the right choice for many kinds of projects. If you're working on a small app or something with a lot of UIs to develop, I would look elsewhere for a communications framework. It also has out-of-the-box bugs in LVRT that require making a branch to repair, so I don't use it on RT targets either.

See, I tend to think AF is quite appropriate in applications with lots of UIs.  The launch and stop mechanisms are already written, communication between the UIs and the rest of the application is already worked out, and the UIs are easy to write.  Because of this, the framework greatly simplifies model-view-controller designs.  Why would I not use AF in that case?

Also, point of order, the out-of-the-box bugs are with LabVIEW RT, not with AF.  The issue is with community scoping on VxWorks; any application that uses community scoping is problematic.

Back to topic, AF is apprpriate anywhere where you might have used multiple parallel queue-driven message handlers in the past, though Daklu's caveats regarding performance issues and the technical abilities of the people who will take over maintenance are certainly relevant.

Message 7 of 44
(5,350 Views)

komorbela wrote:

However there are limitations regarding the number of Actors that a regular PC can manage.

I found similar results with a different dynamic-launch framework, and confirmed them with a more-simple, preallocated-clone subVI test.  The time to allocate clones seems to grow non-linearly with the number of clones, so loading clone number 5001 takes a lot longer than clone 101.

0 Kudos
Message 8 of 44
(5,350 Views)

niACS wrote:

See, I tend to think AF is quite appropriate in applications with lots of UIs.  The launch and stop mechanisms are already written, communication between the UIs and the rest of the application is already worked out, and the UIs are easy to write.  Because of this, the framework greatly simplifies model-view-controller designs.  Why would I not use AF in that case?

I concur that the AF is great for MVC patterns.  However, I fear the scalability of the AF for large complex applications with multiple windows.  How does the AF handle thousands of messages? This was also a concern with a few developers I spoke with at NI Week.

For UI heavy applications that only need to communicate a few items between modules, I have considered putting a JKI state machine/QMH in the Actor Core and having the actor messages fire user events.  I find the JKI State Machines much for efficient for development.  There is significant time spent creating methods and messages to update the actor from an Event Structure vs adding a case to a QMH case structure.  Any thoughts?

CLA, CTA
0 Kudos
Message 9 of 44
(5,350 Views)

DavidStaab wrote:

Daklu, you have solid points about actor-oriented design (AOD), but the thread is more about the Actor Framework. There are (as you of course know) other tools that can be used to achieve AOD, and each of those has its own limitations and benefits.

Fair enough. 

My perception is many people do not fully understand the difference between AF actors and actors in general (I'm not even convinced I do), or worse, only consider actors in the context of the AF.  I think it's important for community development and advancing LV technology to talk about actor-oriented programming in general and not restrict the discussions to only the AF.  Still, I do agree I should have been more clear I was referring to AOD and not the AF, and your concern about the RT community scope bug is completely valid.

If you'll forgive me for saying so, I suspect much of the difficulty you're having with the AF--especially with respect to UIs--is due to learning AOD rather than any inherent issues with the AF.  Part of it may be that (imo) the AF is not just a "communication framework" as you mentioned, but an "actor framework."

Message 10 of 44
(5,350 Views)