That’s all. Please refer to the Agha paper for further details. If the above conditions are met, there can’t be any deadlocks.

Yes, Actors do not solve the synchronization problems for a true multi-threaded program. If you think about having multiple Actors communicating in an internet book store app the locking issues have not changed at all from other solutions.

In my tests BlockingQueue in Java creates a massive amount of context switching. Does it make sense to do a thread switch for every tiny message that comes in, and is there any easy way around this?

I know the actor community does not want to discuss usecases where you need to share state.

And Tim has no clue I assume what James wanted to illustrate – that if you have a usecase that needs to share state you can get race conditions and actors will not help you – no technology will help you if your use case needs state sharing. Obviously James example is not about sock dispensers.

Shared state: Are actors part of the application state as a whole: hell yes. Do single actors share their local state: no – not if you and your application architecture comply to the whole idea of actors.

And with all due respect to James Iry and his vending machine: that example in context of actors is total b/s and Tim has said it quite well in
his comment: http://james-iry.blogspot.com/2009/04/erlang-style-actors-are-all-about.html?showComment=1253812155361#c3904292961745027682

Orwellian, for those who use the “share nothing” term outwards to convince others of actors.

It’s more like cats and dogs. They speak different languages.

From the discussion above,what Erlang calls “share nothing” others would call “encapsulation” (see encapsulated Java examples etc.)

So using share-nothing inside Erlang is fine as it describes the fact in Erlang terms, using it outside knowing that others use the term differently (system as you call it), is Orwellian, I stand with that.

I have countless examples in books and academic papers regarding concurrent and distributed systems, defining state in terms of internal object/system state.
I esteem and respect Stephan very much, he’s a very nice person, but I have no interest in convincing someone who defines others’ point of view as “Orwellian”, so I’ll stop my discussion here.

“That said, when talking about “shared nothing architecture” in concurrency models (actors) or distributed systems (take Cassandra as an example), we don’t refer to global application state: we refer to the state, maybe memory is a more appropriate term, of a single actor/system.”

Right.

@Stephan

“a.) This is Orwellian b/c noone else uses this term in that way”

I disagree, in Java Concurrency in Practice, which is by no means a standard, but we all can agree that is a relevant book in the subject, state is defined as the data inside an object “stored in state variables such as instance or static fields”, and the term shared state refers to state variables (read object’s variables) “that could be accessed by multiple threads”. So an Actor which only consumes/produces messages doesn’t share state according to these definition, which I think is the norm when talking about concurrency, at least in Java.

All quotes taken from Chapter 2, first page, in case anybody might want to check :)

http://james-iry.blogspot.com/2009/04/state-of-sock-tubes.html

http://james-iry.blogspot.com/2009/04/erlang-style-actors-are-all-about.html

http://james-iry.blogspot.com/2009/04/but-butyou-didnt-mutate-any-variables.html

And there was another one about locking and Erlang

http://james-iry.blogspot.com/2009/04/erlang-style-actors-are-all-about_16.html

Noone in this thread has argued that.

The bottom line is that the Actor async messaging approach with queued access to actor state is a different way to program concurrent systems than others.

When I program in Google’s Go language with goroutines, my concurrent applications are entirely different in their structure than how I coded applications in the past with Java’s synchronized, util.concurrency library, etc.

Because I’ve been a heavy JMS developer for years building distributed systems, a messaging approach to concurrency via language innate features like goroutines was a very easy uptake. It’s faster for me to develop concurrent applications with this approach and not get bogged down trying to get things right as was the case with the previous approaches.

I wouldn’t argue that it’s an end-all solution for concurrent programming needs, but it’s a useful approach to add to the arsenal and can enable a developer to be more productive. More productive in the sense of how I became significantly more productive back in the day when I switched away from C++ to Java and C#.

but

“Share nothing architecture”

Noone would argue with the internal state claim.

I half agree with you. From the point of view concurrent memory access, actors don’t share their internal state. This property is easy to implement in standard class with proper encapsulation and immutable method parameters/return values. If your looking at the state of all the actors and the dependencies between each other, I’d call that distributed state, not shared state. On the other hand, I agree with your assessment of the locking situation.

As James said, and I agree with him,
a.) This is Orwellian b/c noone else uses this term in that way
b.) Memory is irrelevant

See above then every Java object with sync methods and getters/setters also is a shared nothing architecture.

I don’t think we add anything new to the discussion. It boils down to:

Me,James,others: If two actors depend on the internal state of a third actor, they are sharing state.

You,Erlang community: If two actors depend on the internal state of a third actor, they are not sharing state.

That said, when talking about “shared nothing architecture” in concurrency models (actors) or distributed systems (take Cassandra as an example), we don’t refer to global application state: we refer to the state, maybe memory is a more appropriate term, of a single actor/system. In such a case, and with such a state definition which isn’t Orwellian either, actors clearly don’t share state.

(with the very senseful definition of state by James).

Anyways, discussion seems to have been somewhat drifted toward implementation details and the “are actors the concurrency silver bullet” question, which wasn’t the original one and isn’t interesting either because of the obvious answer.

Going back to the discussed myths …
1) Are actors a shared nothing system? Yes, because actors don’t share state, but send messages instead: it’s true those messages may *depend* on internal state, but this doesn’t mean to *share* state.
2) Are they easier to get right because of that? It depends on your mindset and what you’re trying to accomplish. Once you shift your mind toward asynchronous message passing, actors will let you think in terms of message flows without caring about what to share and what to lock and how to do to avoid liveness problems, which is an advantage. But still, many prefer locks and explicit concurrency.

Obviously, you can implement actors in several ways, and you can also implement asynchronous systems that work similar to the actor one.
And obviously, you can misimplement and screw up everything even when using the actor model, no system will ever save us from our own mistakes.
But that’s another story ;)

Cheers!

Sergio B.

Discussing whether or not a two-actor system constitutes a shared-nothing architecture is a misapplication of the concept. Of course if you have one actor depending upon another, the first actor depends transitively on the second actor’s state– but that’s not the kind of sharing to which the phrase “shared nothing architecture” refers. That’s why nobody ever argues over whether a system with a single app server and a single database node is “shared nothing”; there’s only one app server, so with whom would it be sharing the database?

Whether or not an architecture is shared-nothing doesn’t really become a question until you have at least three actors.

Helpful diagram: http://imgur.com/6LJe5.png

http://scalaz.googlecode.com/svn/continuous/latest/browse.sxr/scalaz/concurrent/Promise.scala.html

as promised my little comment.

Somehow I dislike the term actor. Communicating Sequential Processes (CSP) by Tony Hoare describes the idea better. Software based on this idiom consists out of a large number of light weighted processes processing messages sent to them sequentially. In Erlang/OTP each processes only has one inbox but a very flexible pattern matching, in Go goroutines can listen to multiple channels parallely while those channels can also be listened by multiple goroutines.

After a short time this way becomes a very natural kind of thinking. It is a very good base for concurrent software, but it’s not the panacea without any problems. Synchronous request with answers need a kind of request/response messaging which without timeouts can easily lead to deadlocks (A calls B calls C calls A). This can be dismantled by timeouts, like in Erlang/OTP, but here this means a new level of error handling complexity (is it a deadlock or just a real timeout, because one process has a high load).

So back to the myths:

(1) Actors encapsulate their internal states, yes, and they don’t share it directly. But state changes depend on the messages the actors receive. So I won’t call it “share nothing arch” but “share actors arch”.

(2) From my experiences it’s definitely a very simple idiom for the creation of massive concurrent applications. It removes many pitfalls and makes it easier to not forget semaphores or synchronized blocks. But a brings some new problems – single processing loop – and definitely doesn’t solve every problem (deadlocks, partitioning of problems). So one has to learn how to use actors/CSP/MPI the right way.

One could of course respond “if you need fork/join parallelism, use the fork/join framework”, sure enough. Which is part of the point, actors do not seem the universal be-all, end-all programming model for concurrency, and we (well, at least I) have yet to figure the precise cases where it is the best-fitting solution. If anyone has such a characterization, of when actors is the best choice over other programming models, I would be very interested in it.

Something that has always puzzled me is that actors do share a single synchronization point: their message inbox. Instead of having these locks spread over several synchronized methods (the Java way), you are now funneling all your methods in this single inbox. The claims are that locking in the inbox can be made very fast and is never a bottleneck, but I wonder.

You’re right, actors do share their state because there exists a dependency between an actor’s state and the messages that it sends.

Of course, the exact representation of the state cannot (properly) be observed from the outside, but if an actor has state, it’s implicitly shared if the messages that it sends to other actors depend on its state.

Sharing is still possible, of course.

Writing should be done asynchronously, through the actor and will be performed synchronously by that same actor.

You can think of multiple solutions for reading. I would use event sourcing and local caching in the consuming actors. Also used in cqrs (& its circular architecture).

How so?

The model obviously works for many queues with each consumer working as a producer and vice versa.

@Sushrut: No, please argue with the post. If your usecase describes shared data (tickets), then you cannot partition the solution in any way to not share data (at least that I know of).

More actors do not solve the problem.

And if your usecase does not involve sharing data, then well, why should you share data with any concurrency model?

The real work is not in the implementation of one actor, but in partitioning your model in such a way that these actors really represent asynchronous parts/components/aggregates in your domain model.

Conceptually, it’s going back to the roots of OO, where Objects are fully encapsulated and can only message to each other (the way Alan Kay meant it to be).

Concluding, (and @Dimitris) so the hype is a bit undeserved, it’s mostly doing away with threads. Of course one should embrace it fully and only use one-way, asynchronous messaging (preferably eventing). So no request-response look-a-likes. This way, locking, race conditions and the like will not be a problem any more. Does this pose a formidable design challenge? Yes it does.

” I was quite annoyed with the sheer audaciousness of it.”

I often feel the same.

It’s not the new concurrency. It’s a slightly higher level programming interface, a bit cleaner than MPI, and it’s important to note that all the usual concurrency problems are *still here with us* (deadlocks, races, etc, all can be easily simulated). Seeing some slides of a JavaOne conference, titled, “Concurrency – You are doing it wrong” (basically claiming that using java.util.concurrent is wrong, we should be using actors instead, that’s the “true way” now!), I was quite annoyed with the sheer audaciousness of it.

I currently prefer lower level tools, more control, more easy to reason about performance, and so on. Actors are also good, I might use them more when the hype has died down.

And the problem goes away when using async send, which I wrote in the post.

Yes, because the actor acts as a semaphore (wlock).

Waiting for your post :-)

You are talking about sharing state. If your definition of sharing is: “they have a way of viewing and changing the same data” – I agree.

The key point here is that it’s the actor that contains the state that is synchronizing these reads and writes.

So, yes, you can simulate actors bij having threads and locks and different actors can ’share state’ by messaging to the same third actor. The important difference is, however, that they cannot cause two threads to run through the same actor, at the same time.

All of this means that actors could be in completely different processes, on different hardware even. Now that’s a difference with threads running through the same, synchronous model.

And actually, all of this doesn’t mean actors have unique possibilities, far from it. It actually means you do not use a certain possiblity: multiple threads (on the same state/objects).

For this to work, one needs another way of having concurrency, that is where partitioning your model in smaller components comes in. I therefore think ‘Actors’ should contain ‘Aggregates’. I’ll be blogging/presenting about this soon.

“Second, actors don’t need locks on their own state, because it’s accessed by one and only one thread: [...]”

Sometimes people say an actor has a thread (lightweight), but I think it’s better to think of the mailbox being a queue with one worker thread, the actor.

Pseudo Syntax:

class C1 {
TicketManager m = ...
}

def synchronized dec() {
if (tickets > 0) tickets--;
}
}


Neither C1 or C2 see the “state” in TicketManager. But obviously they share indirectly the tickets state.

Second: Well this was my explaination why actors do not have liveness and deadlock problems, but it’s not because they have no semaphores an not because they do not share state.

Second, I’ve got your point but again, you have to switch your point of view from “no locks/semaphores” to “no liveness problems”: does it clarify?

Several actors share the state of the TicketActor by holding references to the TicketActor and synchronizing via the mailbox of the TicketActor.

Second: The accessing by only one thread and a sequential mailbox is essentially a lock – you do not need to have a lock class to have a lock. Perhaps I should have better used the word semaphore.

I think you have two bugs in your reasoning.

First, even if actors actually have state, they don’t make it leak to the outside: they just sit there waiting for messages, I don’t see how you see this as a sharing mechanism.

Second, actors don’t need locks on their own state, because it’s accessed by one and only one thread: don’t take the JVM as a reference, where locks are needed for ensuring memory visibility. Also, the correct way to interpret the statement “actors have no locks” is: actors have no contended or composed locks, that is, they don’t have liveness problems.

Let me know if I misunderstood your reasoning ;)

Cheers!

Sergio B.