Actor model to replace the threading model?

It's not so much that the actor model will replace threads; at the level of the cpu, processes will still have multiple threads which are scheduled and run on the processor cores. The idea of actors is to replace this underlying complexity with a model which, its proponents argue, makes it easier for programmers to write reliable code.

The idea of actors is to have separate threads of control (processes in Erlang parlance) which communicate exclusively by message passing. A more traditional programming model would be to share memory, and coordinate communication between threads using mutexes. This still happens under the surface in the actor model, but the details are abstracted away, and the programmer is given reliable primitives based on message passing.

One important point is that actors do not necessarily map 1-1 to threads -- in the case of Erlang, they definitely don't -- there would normally be many Erlang processes per kernel thread. So there has to be a scheduler which assigns actors to threads, and this detail is also abstracted away from the application programmer.

If you're interested in the actor model, you might want to take look at the way it works in Erlang or Scala.

If you're interested in other types of new concurrency hotness, you might want to look at software transactional memory, a different approach that can be found in clojure and haskell.

It bears mentioning that many of the more aggressive attempts at creating advanced concurrency models appear to be happening in functional languages. Possibly due to the belief (I drink some of this kool-aid myself) that immutability makes concurrency much easier.

I made this question my favorite and am waiting for answers, but since there still isn't, here is mine..

Why and how an actor model can be an advanced concurrency model that replaces the threading?

Actors can get rid of mutable shared state, which is very difficult to code right. (My understanding is that) actors can basically thought as objects with their own thread(s). You send messages between actors that will be queued and consumed by the thread within the actor. So, whatever state in the actor is encapsulated, and will not be shared. So it is easy to code right.

see also http://www.slideshare.net/jboner/state-youre-doing-it-wrong-javaone-2009

What other models are the 'advanced concurrency model'?

see http://www.slideshare.net/jboner/state-youre-doing-it-wrong-javaone-2009

See Dataflow Programming. It's an approach, which is a layer over top of the usual OOP design. In some words:

• there are a scene, where Components resides;
• Components have Ports: Producers (output, which generate messages) and Consumers (input, which process messages);
• there are Messages pre-defined between Components: one Component's Producer port is bind with another's Consumer.

The programming is going on 3 layer:

• writing the dataflow system (language, framework/server, component API),
• writing Components (system, basic, and domain-oriented ones),
• creating the dataflow program: placing components into the scene, and define messages between them.

Wikipedia articles are good starting point to understand the business: http://en.wikipedia.org/wiki/Flow-based_programming See also "actor model", "dataflow programming" etc.