Jump to content

need help dipping my toe into Actor programming

Recommended Posts

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.

Link to comment

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.

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.