Concurrent Processing and Distributed ComputingA case study on Akka and Scala

Rahul Ramteke-2K13/SE/066

What is concurrent processing?

Concurrent processing is a computing model in which multiple processors execute instructions simultaneously for better performance. Concurrent means something that happens at the same time as something else. Tasks are broken down into subtasks that are then assigned to separate processors to perform simultaneously, instead of sequentially as they would have to be carried out by a single processor.

Concurrency methodologies

When you look at the topic of concurrency in the general sense, there really are only two types: shared-state concurrency and message passing for concurrency. Shared-state concurrency has dominated for a long time, but before it did, the idea of message passing was the mainstay. Multiprocessing was used to carve up work between processes on a machine, and communication between those processes was accomplished using file descriptors on which you could simply read and write. This was message-passing in its most primitive form.

Shared State concurrency

When using shared state concurrency, the threads tend to use the same memory address for computations and processing. This type of concurrency has been profoundly used in java and c#.

Shared State Concurrency has the following advantages...

• Can be very fast.

• Makes Global Consensus much easier to achieve

• Makes passing around Reference Objects that much easier, especially if a pointer/reference valid in one process is valid in another.

Message passing concurrency

Concurrent components communicate by exchanging messages (exemplified by Scala). The exchange of messages may be carried out asynchronously, or may use a synchronous "rendezvous" style in which the sender blocks until the message is received. Asynchronous message passing may be reliable or unreliable (sometimes referred to as "send and pray"). Message-passing concurrency tends to be far easier to reason about than shared-memory concurrency, and is typically considered a more robust form of concurrent programming.

introduction to akka and scala

Scala, to many, is a programming language which compiles to Bytecode and has functional features. To me, it’s more of a paradigm. The name does indicate that scalability is involved somewhere and it actually is. As they say, scala grows with you.

Akka is a toolkit that specializes in easing the task of concurrency for the beginners and being an ultimate concurrency resource for seasoned devs. You can think of it as a framework which is strongly based on actor model.

The actor model

The Actor model adopts the philosophy that everything is an actor. This is similar to the everything is an object philosophy used by some object-oriented programming languages, but differs in that object-oriented software is typically executed sequentially, while the Actor model is inherently concurrent.

An actor is a computational entity that, in response to a message it receives, can concurrently:

• send a finite number of messages to other actors;

• create a finite number of new actors;

• designate the behavior to be used for the next message it receives.

• There is no assumed sequence to the above actions and they could be carried out in parallel.

The working of akka

As i said before, scala to me is a paradigm and so is akka. It opens your mind when it comes to concurrency, allows you to think in new and better ways. Let’s see how it actually works.

Akka is based on actor model. So, yes, actor is the atom here. The actor does most of the heavy lifting in our applications due to its flexibility,its location independence,and its fault tolerant behaviour. But even beyond these features, there’s an interesting consequence of the actor design—it helps make concurrency development more intuitive.

The working of akka

o Messages come into a mailbox through (unless you want otherwise) a non-blocking enqueue operation.

• This allows the caller to go about his business and doesn’t tie up a waiting thread.

o The enqueue operation wakes up the dispatcher who sees that there’s a new message for the actor to process.

o The dispatcher sends the message to the actor and the actor processes it on whatever thread it was put on to do the work.

• During the time when the actor is processing the message, it’s in its own little world.

• It can’t see other messages being queued and it can’t be affected by anything else that’s happening elsewhere.

o Eventually, the actor will finish processing the message.

A sample akka code in scala

Apparently calculating 22/7 through your code isn’t enough for calculating pi.

𝑛=0∞ −1 ^𝑛

2∗𝑛+1= Pi/4

So, here we have a code which calculates value of pi to a certain precision, which depends on the value of ‘n’ and the limits of the data type used.

Doing it the java way

Had it been plain old java. The imperative style would have forced us to do it the old way of having mutable objects, having threads, and synchronizing them to prevent deadlocks. You can imagine what a mess it would have been.

Not saying that java is bad for concurrency. But isn’t good too when you actually need scalability. As seen in the code,I can Actually scale the scala code for n=200 million in 8-10 lines and 2 minutes. And the optimum core use is handled by akka.

The working of akka

As i said before, scala to me is a paradigm and so is akka. It opens your mind when it comes to concurrency, allows you to think in new and better ways. Let’s see how it actually works.

Akka is based on actor model. So, yes, actor is the atom here. The actor does most of the heavy lifting in our applications due to its flexibility,its location independence,and its fault tolerant behaviour. But even beyond these features, there’s an interesting consequence of the actor design—it helps make concurrency development more intuitive.