# Asynchronous programming with Scala Futures

Asynchronous programming can be a daunting subject when first encountered by programmers. This post aims to serve as an introductory tutorial for asynchronous programming using the Future construct in Scala.

For a more in-depth look at asynchronous programming with Scala, check out the official docs.

## Why asynchronous?

Consider that we have to execute $N$ independent tasks, denoted by $T_1, T_2, ..., T_n$. One approach is to execute them sequentially, as is commonly seen in synchronous programming (Fig. 1):

Although this may be sufficient in many cases, it may not be sufficient if all $N$ tasks are required to be completed with a certain time constraint. Furthermore, one or more of the tasks in the collection may take much longer to complete than others, thus becoming a bottleneck. For example, assume that $N = 10$. Now, if $T_2$ takes 50 minutes to complete while the other nine tasks take $% $ minute, tasks $T_3, T_4, ..., T_n$ will unnecessarily wait for $T_2$ to complete, despite being independent from it.

A more efficient approach may be to launch all $N$ tasks in parallel (Fig. 2). The number of tasks that are effectively executed in parallel is termed the parallelism level or degree of parallelism. In practice, the parallelism level is limited by the number of threads and/or cores in the processor.

Another approach is to only launch certain tasks asynchronously, such as those that run much longer than others (Fig. 3). Coming back to our example where $T_2$ runs much longer than other tasks, we can launch $T_2$ asynchronously after $T_1$. By doing this, the execution will immediately move on to $T_3$ without waiting for $T_2$ to complete, while $T_2$ will continue to run on a separate thread. When $T_2$ completes, its result can be obtained using a callback (discussed shortly).

## Parallelism vs concurrency

Before proceeding, it is important to distinguish between parallelism and concurrency. Although they may look like synonyms in everyday usage, these terms are defined differently in computer science.

For an interesting detailed discussion, refer to Jenkov’s excellent blog post. Briefly, concurrency represents tasks that seemingly run in parallel, while parallelism represents tasks that actually run in parallel. When a processor runs tasks concurrently, they may all be making progress, but the processor is actually only running one or a subset of them at any instant in time. This is usually achieved by rapidly switching context from one task to another. On the other hand, when a processor is running tasks in parallel, it is actually running all of them simultaneously.

So where does asynchronous programming fit in then? Well, it may imply either concurrency or parallelism. If the processor supports running tasks in parallel, asynchronously launched tasks will run in parallel. If the processor can only run one task at a time, asynchronously launched tasks will run concurrently.

## Asynchronous programming in Scala

Scala provides simple, elegant high level APIs to execute code asynchronously. This section briefly discusses Futures and related concepts.

### Using Futures

Simply put, the aptly named Future object represents any code that may run asynchronously and produce a result in the future.

Here’s an example of a Future:

Note the import. This is an implicit global static thread pool that is used to execute the Future. It is also possible to explicitly specify an ExecutionContext with a user-defined thread pool; for a detailed discussion please refer to the official docs.

The sorted value here is a Future that embodies the result of the long lasting sort operation.

### Callbacks

Usually, we are interested in obtaining the results from an asynchronous computation. This can be achieved by using a callback. A callback is simply a function that is called when a Future is completed. Since higher-order functions are first class citizens in Scala, the definition of callbacks is easily achieved.

For a Future, a callback is typically registered by supplying a function of type Try[T] => U to the onComplete method. If the Future is successful, the supplied callback is applied to the value of type Success[T], or to a value of type Failure[T] otherwise.

Coming back to our sorting example, we can now register the callback as follows:

If the Future is successful, the sorted sequence will be printed. If, for any reason the Future fails, the exception message will be printed.

### Scaling Futures

Suppose we need to launch 100 tasks in parallel, and then do something with the results of the 100 tasks. Creating one future per task and registering a callback for each would be extremely tedious, not to mention unscalable. One solution is to create a sequence of Future[T] objects and convert this Seq[Future[T]] object into a single Future[Seq[T]] object, so we can do something with the results collected from all futures.

An example will help illustrate the idea:

On line 24, we’re converting a Seq[Future[String]] object into a Future[Seq[String]] object. Note that internally, what this actually does is:

1. Executes the Futures in the sequence asynchronously
2. Once all Futures are complete (whether successfully or otherwise), combines the result of all Futures into a Future[Seq[String]] object.

However, there is a problem with this code. We’re defining three Futures, and one of them throws a RuntimeException. Can you guess what will happen here?

Here’s the output:

Task 1 running!


Oh wait, where are the results of the tasks that we’re printing on line 27?

### Composing Futures

The reason the results of the tasks were not printed to the console is as follows: If any of the Futures in a sequence of Futures fails, the onSuccess function does not get executed. And since we did not define an onFailure function, the exception was ignored! What now?

Scala’s powerful functional personality comes to the rescue again! Scala allows composing Futures using combinators. Briefly, combinators are functions that operate on Futures and return new Future objects. Scala providers several types of combinators, including flatMap, filter, foreach, etc.

One particular combinator that will help resolve our sticky situation is recover. When applied on a Future, the recover combinator allows intercepting an exception and doing something with it, and potentially returning a default value instead. Using recover, we can rewrite our example as:

Output:

Task 1 running!