Difference in definition of Actors vs Threads? [duplicate]

Question

I'm trying to understand the difference in definition of Actors and threads. Some articles say that actors are lightweight threads, while other articles states that actors are not threads. I also understand that a thread can run multiple actors. I'm confused as to how to exactly differentiate actors from threads. Please help me understand thanks!

Answer 1

Actors are at a higher level of abstraction when compared to Threads.

Thread is a JVM concept, whereas an Actor is a normal java class that runs in the JVM and hence the question is not so much about Actor vs Thread, its more about how Actor uses Threads.

What is an Actor?

At a very simple level, an Actor is an entity that receives messages, one at a time, and reacts to those messages.

How does Actor use Threads?

When Actor receives a message, it performs some action in response. How does the action code run in the JVM? Again, if you simplify the situation, you could imagine the Action executing the action task on the current thread. Also, it is possible that the Actor decides to perform the action task on a thread pool. It does not really matter as long as the Actor makes sure that only one message is processed at a time.

Answer 2

I'm trying to understand the difference in definition of Actors and threads.

Honestly, they really don't have much to do with each other, so it is kinda hard to talk about their difference. It's like talking about the difference between a Toyota Camry and the color blue.

An Actor is a self-contained, encapsulated entity that communicates with other self-contained, encapsulated entities purely by sending messages.

Now, if that sounds exactly like the definition of Object to you, you are right! There is a deep connection between Actors and Objects: the Actor Model of Computation was conceived by Carl Hewitt, partially based on the Message-Directed Execution of early Smalltalks (Smalltalk-71, Smalltalk-72). Alan Kay, in turn, cites PLANNER' Goal-Directed Execution as a heavy influence on Smalltalk's Message-Directed Execution … PLANNER in turn had been designed by Carl Hewitt. (PLANNER is also the precursor to Prolog, which in turn was the precursor to Erlang; Erlang is based on Prolog, started out as a library in Prolog, and the first implementations were written in Prolog.) Also, both Carl Hewitt and Alan Kay cite the early work of Vint Cerf and Bob Kahn on what would later become the Internet as inspiration, and both of them were heavily inspired by nature, Carl Hewitt by physics and Alan Kay by microbiology. So, the deep connections and similarities are very much not surprising.

Actors and Objects are pretty much the same thing. We usually expect Message sends in Object-Oriented Systems to be synchronous, instantaneous, reliable, and ordered, while no such guarantees exist for Actors. That is the main difference between Actors and Objects: Actors are Objects where Messages may get lost, re-ordered, take a long time, and are asynchronous. (The only guarantee is that a Message may get delivered At Most Once.) Also, the Receiver of a Message typically has no implicit reference to the Sender, so if the Receiver wants to reply to the Message, the Sender needs to pass its own reference along with the Message (unlike typical Object-Oriented Systems, where I can always return something to the Sender).

An Actor can do three things, and exactly those three things and nothing more:

1. Create new Actors
2. Send Messages to Addresses of Actors it already knows (i.e. Addresses of Actors it created, and Addresses it got sent in a Message)
3. Designate how to handle the next Message (this is essentially how to model mutable state)

Note that in order to send a Message to an Actor, you need to have an Address for the Actor. You can only send Messages to Addresses. An Actor may have multiple Addresses, and multiple Actors may be hidden behind a single Address. Addresses are unforgeable, you cannot construct one yourself, you have to have it handed to you. (This is an important difference to pointers in C, and more like object references in Java.)

There is a very nice video of a whiteboarding session (mostly) between Carl Hewitt himself and Erik Meijer about Actors on Microsoft's Channel9 community website: Hewitt, Meijer and Szyperski: The Actor Model (everything you wanted to know, but were afraid to ask). It explains among other things the fundamental ideas behind Actors as well as the fundamental Axioms of Actors in an accessible way.

Carl Hewitt was also invited to give a lecture at Stanford's EE380 Computer Systems Colloquium, where he talked about How to Program the Many Cores For Inconsistency Robustness, including an introduction to Actors.

Threads, OTOH are just strands of execution. They are essentially nothing but an instruction pointer and a call stack. In particular, Threads don't have memory (of their own). All Threads of a Process share the same memory. Which means among other things, that a single misbehaving Thread can crash all Threads of the Process, and that all access to this shared memory must be carefully controlled.

Some articles say that actors are lightweight threads, while other articles states that actors are not threads. I also understand that a thread can run multiple actors.

You are confusing the concept of an Actor with a possible implementation.

A very simple implementation of Actors in an existing environment would be to make every Actor a Process. That's how BEAM (the dominant implementation of Erlang) works, for example. This works, because on BEAM, Processes are extremely cheap and lightweight; a process only weighs about 300 Byte, and there can be tens of millions of Processes on a cheap 32 Bit single-core laptop from 10 years ago. This would not work with Windows Processes, for example, which are much more expensive.

There is also an implementation of Erlang on the JVM (called Erjang) which uses Kilim, an implementation of extremely lightweight Actors on the JVM using bytecode re-writing. (Note that both Erjang and Kilim appear to be dead.)

If you want to implement Actors on Threads, you have the problem that Actors are completely isolated, whereas Threads are completely shared. So, you need to provide this isolation somehow.

A common way to implement Actors on systems such as the JVM, is to implement Actors as Objects, and then schedule them to run on a Thread Pool to get the asynchronous properties. That's how Akka works.