What is Event Driven Concurrency?

Question

I am starting to learn Scala and functional programming. I read this book! Scala Programming: A Multi-Core Complexity Solution in the Java Virtual Machine. "In the first chapter, I saw the word Event-Driven concurrency and the Actor model. Before continuing with this book, I want to have an idea of ​​the Event-Driven concurrency or Actor model.

What is Event-Driven concurrency, and how is it related to the Actor model?

Answer 1

An event-driven programming model involves registering the code that must be executed when this event fires. For example, instead of calling a method that returns some data from a database:

val user = db.getUser(1) println(user.name) 

Instead, you can register a callback that will be triggered when the data is ready:

 db.getUser(1, u => println(u.name)) 

In the first example there was no concurrency; The current thread blocks until db.getUser(1) returns data from the database. In the second example, db.getUser will immediately return and continue executing the following code in the program. In parallel, the callback u => println(u.name) will be executed at some point in the future.

Some people prefer the second approach, as this does not mean hungry puzzles. Threads need to wait for slow I / O.

The Actor model is an example of how Event-Driven concepts can be used to help a programmer easily write parallel programs.

From a super-high level, Actors are objects that define a series of event-driven message handlers that fire when an Actor receives messages. In Akka, each instance of an Actor is a single Thread, however, when many of these Actors are assembled together, they create a system with concurrency.

For example, Actor A can send messages to Actor B and C in parallel. Actor B and C can send messages back to Actor A Actor A would have message handlers to receive these messages and act as desired.

To learn more about the Actor model, I would recommend reading the Akka documentation. This is really well written: http://doc.akka.io/docs/akka/2.1.4/

There is also a lot of good documentation throughout the site about Driven concurrency events, which are much more detailed to us than what I wrote here. http://berb.imtqy.com/diploma-thesis/original/055_events.html

Answer 2

Theon's answer gives a good modern overview. I would like to add a historical perspective.

Tony Hoar and Robert Milner developed mathematical algebra for the analysis of parallel systems (Sequential Process Communication, CSP and Communicating Concurrent Systems, CCS). Both of them look like hard mathematics for most of us, but the practical application is relatively simple. CSP led directly to the Occam programming language among others, with Go being the newest example. CCS has led to the calculus of Pi and contact channel mobility, a feature that is part of Go and has been added to Occam in the last decade or so.

CSP concurrency models are pure, looking at self-similar objects ("processes", "bright" things, such as green threads), interacting simply by exchanging events. The environment for the passage of events goes through the channels. Processes may have to deal with several inputs or outputs, and they do this by first selecting a ready-made event. Events usually transfer data from the sender to the recipient.

The fundamental feature of the CSP model is that a couple of processes interact only when they are ready - in practical terms, this leads to what is usually called synchronous communication. However, actual implementations (Go, Occam, Akka) allow you to buffer channels (normal state in Akka), so that instead of blocking the exchange of events was actually disabled.

Thus, the event-driven CSP-based system is indeed a network of data streams connected by channels.

In addition to event-based CSP interpretation, there were others. An important example is the event-wheel approach, once popular for modeling parallel systems, while it actually had a single processing flow. Such systems process events by placing them in the processing queue and processing them properly, usually through a callback. A good example is the Java Swing event handling engine. There were others, for example. for time-based modeling mechanisms. You might think of the Javascript / NodeJS model as appropriate for this category.

So the event wheel was a way to express concurrency, but without parallelism.

The irony is that the two approaches that I described above are described as events, but what they mean by the action of an event is different in each case. In one case, hardware elements are connected together; in another, almost all actions are performed by callbacks. The CSP approach claims to be scalable because it is completely complex; naturally, he also knows how to perform parallel execution. If there is any reason to approve one over the other, this is probably it.