need help dipping my toe into Actor programming

[jcarmody]

Can someone recommend a simple actor-oriented architecture?  That's a subjective question, I know...

 

Many years ago I wanted to try my hand at OO programming, so I picked Java and began coding an application which ended up with an enormous main() method that did nearly everything (poorly, too).  I clearly didn't get OO; I knew that I was using the language incorrectly but I didn't know how to begin.  I later took a Java course which removed the mental block and I was able to refactor my code to use appropriate objects, each with their own properties and methods.  It was beautiful  Extending the application became ridiculously easy.

 

I have a similar mental block with actors.  Please help me take a step, there's a roadblock that I just can't see past.

 

Thank you.

[lvb]

I highly suggest reading daklu's (Dave Snyder) various posts on Lava and the NI community.  This is a good start:

 

[NIWeek 2013] What a Software Architect Needs to Know When Using the Actor Framework

 

 

-Brian

[GregFreeman]

Suggested Link

 

I like that link. Gives a good basis for things. I, however, prefer my frameworks to dynamically launch actors because when I do truly require something to be launched dynamically such as multiple windows etc, the caveats are already built in (who owns the lifetime of the queue refs etc). On RT though, I tend to use static processes since not much is ever launched dynamically, except my TCP manager I reuse. 

 

I wouldn't think of an actor in too complex a way. You have been using actors all along, even if they are not OO. It's just a parallel process that is used to accomplish a specific task. What is nice about OO is you can make the incoming queue reference to an actor private, forcing you to define public methods to send it messages, leaving you with a nice API of what the actor can do. Dave shows this nicely in the thread that I have linked. It should be noted, queues are not the only way to implement actors, but I find them to be the most straightforward transport mechanism when transitioning to OO Actor Oriented Programming.

[drjdpowell]

I have recently added a Sample Project to my “Messenging” package that reworks the NI standard sample “Continuous Measurement and Logging”.  I didn’t do it to illustrate actors, per se, but perhaps the comparison will help.  

 

To me, the key point about “actors” is that they are parallel processes that only receive incoming information via a single communication point.  No shared DVRs/FGVs/whatever.  Actors are parallel processes, but with design restrictions, restrictions that are intended to make them more robust against the kind of bugs that can afflict multiple interacting parallel processes.