Win a flower (🌹) or copy of Real-World Software Development: A Project-Driven Guide to Fundamentals in Java (📚) this week in the Agile and Other Processes forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Liutauras Vilda
  • Knute Snortum
  • Bear Bibeault
master stewards:
  • Devaka Cooray
  • Jeanne Boyarsky
  • Junilu Lacar
garden masters:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • salvin francis
gardeners:
  • Tim Holloway
  • Piet Souris
  • Frits Walraven

The Actor Model

 
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, I'm having trouble understanding the Actor Model and the concurrency behind it.

1. I know that concurrency means multithreading but how does multithreading relate to Actors?
2. What does it mean when Actors do not have a shared state? What is this "state" exactly? And how do Actors not have a shared state between each other?
3. What does the Actor Model "achieve" exactly?
4. "Messages" within Actors could be basically anything you wish to send from one Actor to another? An example would be great here!
5. How do Actors create parallel execution as stated here on this site.
6. How do Actors have an advantage over Threads? Amount of memory used, the amount of Actors to Threads ratio, the message-passing effect, etc.

If someone could go in-depth on each of these questions, but keep it simple to comprehend, that would be great.

Thanks!
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Joshua Rodrigues wrote:1. I know that concurrency means multithreading but how does multithreading relate to Actors?


An actor system will normally allow you to run multiple actors concurrently, in different threads. The actor system will take care of all the threads for you, you don't need to manage the threads yourself.

Joshua Rodrigues wrote:2. What does it mean when Actors do not have a shared state? What is this "state" exactly? And how do Actors not have a shared state between each other?


State = mutable member variables. Shared state is state to which multiple actors have access. With actors, you don't have this - each actor can have its own member variables, but actors cannot access the member variables of other actors directly. That is good, because it means that they can't mess each other's member variables up, and you get rid of multi-threading issues - each actor runs in one thread at a time, so there are never multiple threads that try to change the same member variables at the same time.

Joshua Rodrigues wrote:3. What does the Actor Model "achieve" exactly?


It makes it a lot easier to write concurrent applications, because you don't have to worry about the low-level details of managing threads and synchronizing access to data.

Joshua Rodrigues wrote:4. "Messages" within Actors could be basically anything you wish to send from one Actor to another? An example would be great here!


Yes, any kind of object, but those object should be immutable, otherwise different actors might accidentally change each other's data.

Joshua Rodrigues wrote:5. How do Actors create parallel execution as stated here on this site.


The actor system takes care of that for you. It will probably use a thread pool to manage the threads, but it's really up to the particular implementation of the actor system.

Joshua Rodrigues wrote:6. How do Actors have an advantage over Threads? Amount of memory used, the amount of Actors to Threads ratio, the message-passing effect, etc.


Threads are a low-level concurrency mechanism. When you program with threads, you have to take care of a lot of details yourself, for example making sure to shared mutable data is synchronized, etc. It's very easy to forget to synchronize properly or make subtle bugs or cause deadlocks, which will make the program behave unpredictably. Writing correct software using threads is hard. Actors make it a lot easier, because the actor system will take care of most of the low-level details and hard parts.

The idea of actors is easy and intuitive to understand. An actor is a "live" object - an object that is executing code, and that talks to other actors by sending them messages. Think about people working together, and talking to each other. That's how actors work. The people working together are each doing their own thing, and they are all working concurrently. Each person has his or her own memory to store information in. Other people don't directly change the information stored in someone's memory. Instead, they say something (= send a message) to the other person.

Have a look at Akka, which is probably the most popular actors library for Scala and Java.
 
Joshua Rodrigues
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just two more questions - the first one is about Event-Driven Actors. When it comes down to Events, do Events process the Messages, redirect the Messages elsewhere, or what exactly? What exactly does an Event do within the Actor Model? In my project that contains Actors, Events handle the Messages. Is this correct or am I doing something wrong?

Second Question - running multiple Actors concurrently? Do the Actors themselves become concurrent or do the Messages become concurrent or both maybe? When it comes down to concurrency, I usually use the newFixedThreadPool - which is what I am using for messages (wrong or correct?). How would I go about using a ThreadPool for Actors? Would I need to make the Actor extend the Runnable interface and then submit the Actor into the new newFixedThreadPool? Sorry, I'm still kind of new to concurrency and Actors.

Thanks!
 
Jesper de Jong
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Joshua Rodrigues wrote:Just two more questions - the first one is about Event-Driven Actors. When it comes down to Events, do Events process the Messages, redirect the Messages elsewhere, or what exactly? What exactly does an Event do within the Actor Model? In my project that contains Actors, Events handle the Messages. Is this correct or am I doing something wrong?


I don't know what specifically "event-driven actors" means. As far as I know the "event-driven" is not a concept that is specifically associated with actors. Maybe in the context of some specific actor system library it has a meaning; you'd have to read the documentation of that library to understand what the authors of the library mean with "event-driven actors" in that context.

An actor has a mailbox, in which it can receive messages. Conceptually, the actor is constantly looking at its mailbox, and whenever a message arrives in its mailbox it will process it. Actors handle messages one by one (an actor does not handle multiple messages concurrently).

Joshua Rodrigues wrote:Second Question - running multiple Actors concurrently? Do the Actors themselves become concurrent or do the Messages become concurrent or both maybe? When it comes down to concurrency, I usually use the newFixedThreadPool - which is what I am using for messages (wrong or correct?). How would I go about using a ThreadPool for Actors? Would I need to make the Actor extend the Runnable interface and then submit the Actor into the new newFixedThreadPool? Sorry, I'm still kind of new to concurrency and Actors.


No, forget about low-level things such as threads, thread pools and managing concurrency yourself. The point of an actor system is that it will take care of managing threads automatically. An actor is not a Runnable and you don't submit it into a thread pool.

An actor will have a receive() method (what it's actually called depends on the actor library you are using - in Akka, it's called receive()). That method will be called by the actor system when the actor should process a message. The actor should then process the message, for example by doing some computation, and then possibly send messages to other actors. It should return from the receive() method as soon as it has finished processing the message. The actor system will create threads and call the receive() method on a worker thread.

But as I already said, the whole point is that you don't need to worry about the hard parts of writing concurrent programs, such as threads, thread pools and synchronization.

A message is just a simple object that contains some data that the actor can work with. It doesn't have anything to do with thread pools, so "using a newFixedThreadPool for messages" and "messages becoming concurrent" doesn't mean anything.
 
Joshua Rodrigues
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm wondering if I am doing this correctly or not.. Please forgive me if my code looks terrible and/or whether or not I am doing correctly. This isn't even close to complete seeing how I am still working on it. I just wish for a few pointers.

Actor:


ActorUniverse:


Those are the main classes so far. The Message just contains an Enum for its stage and then there's the Address class file. I'm only showing the main ones, but if you wish for me to show more, ask away!
 
Jesper de Jong
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Are you implementing your own actor system from scratch? So far there seems nothing obviously wrong with the code, although it's far from complete.

If I would be building software that uses actors, I wouldn't try to implement my own actor system, I'd use an existing actor system such as what the Akka library provides.
 
I found some pretty shells, some sea glass and this lovely tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!