Learning Concurrent Programming in Scala - Second Edition

5 (2 reviews total)
By Aleksandar Prokopec
  • Instant online access to over 8,000+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Introduction

About this book

Scala is a modern, multiparadigm programming language designed to express common programming patterns in a concise, elegant, and type-safe way. Scala smoothly integrates the features of object-oriented and functional languages.

In this second edition, you will find updated coverage of the Scala 2.12 platform. The Scala 2.12 series targets Java 8 and requires it for execution. The book starts by introducing you to the foundations of concurrent programming on the JVM, outlining the basics of the Java Memory Model, and then shows some of the classic building blocks of concurrency, such as the atomic variables, thread pools, and concurrent data structures, along with the caveats of traditional concurrency.

The book then walks you through different high-level concurrency abstractions, each tailored toward a specific class of programming tasks, while touching on the latest advancements of async programming capabilities of Scala. It also covers some useful patterns and idioms to use with the techniques described. Finally, the book presents an overview of when to use which concurrency library and demonstrates how they all work together, and then presents new exciting approaches to building concurrent and distributed systems.

Publication date:
February 2017


Chapter 1. Introduction


"For over a decade prophets have voiced the contention that the organization of a single computer has reached its limits and that truly significant advances can be made only by interconnection of a multiplicity of computers."

 --Gene Amdahl, 1967

Although the discipline of concurrent programming has a long history, it has gained a lot of traction in recent years with the arrival of multi core processors. The recent development in computer hardware not only revived some classical concurrency techniques but also started a major paradigm shift in concurrent programming. At a time when concurrency is becoming so important, an understanding of concurrent programming is an essential skill for every software developer.

This chapter explains the basics of concurrent computing and presents some Scala preliminaries required for this book. Specifically, it does the following:

  • Shows a brief overview of concurrent programming

  • Studies the advantages of using Scala when it comes to concurrency

  • Covers the Scala preliminaries required for reading this book

We will start by examining what concurrent programming is and why it is important.


Concurrent programming

In concurrent programming, we express a program as a set of concurrent computations that execute during overlapping time intervals and coordinate in some way. Implementing a concurrent program that functions correctly is usually much harder than implementing a sequential one. All the pitfalls present in sequential programming lurk in every concurrent program, but there are many other things that can go wrong, as we will learn in this book. A natural question arises: why bother? Can't we just keep writing sequential programs?

Concurrent programming has multiple advantages. First, increased concurrency can improve program performance. Instead of executing the entire program on a single processor, different subcomputations can be performed on separate processors, making the program run faster. With the spread of multicore processors, this is the primary reason why concurrent programming is nowadays getting so much attention.

A concurrent programming model can result in faster I/O operations. A purely sequential program must periodically poll I/O to check if there is any data input available from the keyboard, the network interface, or some other device. A concurrent program, on the other hand, can react to I/O requests immediately. For I/O-intensive operations, this results in improved throughput, and is one of the reasons why concurrent programming support existed in programming languages even before the appearance of multiprocessors. Thus, concurrency can ensure the improved responsiveness of a program that interacts with the environment.

Finally, concurrency can simplify the implementation and maintainability of computer programs. Some programs can be represented more concisely using concurrency. It can be more convenient to divide the program into smaller, independent computations than to incorporate everything into one large program. User interfaces, web servers, and game engines are typical examples of such systems.

In this book, we adopt the convention that concurrent programs communicate through the use of shared memory, and execute on a single computer. By contrast, a computer program that executes on multiple computers, each with its own memory, is called a distributed program, and the discipline of writing such programs is called distributed programming. Typically, a distributed program must assume that each of the computers can fail at any point, and provide some safety guarantees if this happens. We will mostly focus on concurrent programs, but we will also look at examples of distributed programs.

A brief overview of traditional concurrency

In a computer system, concurrency can manifest itself in the computer hardware, at the operating system level, or at the programming language level. We will focus mainly on programming-language-level concurrency.

The coordination of multiple executions in a concurrent system is called synchronization, and it is a key part in successfully implementing concurrency. Synchronization includes mechanisms used to order concurrent executions in time. Furthermore, synchronization specifies how concurrent executions communicate, that is, how they exchange information. In concurrent programs, different executions interact by modifying the shared memory subsystem of the computer. This type of synchronization is called shared memory communication. In distributed programs, executions interact by exchanging messages, so this type of synchronization is called message-passing communication.

At the lowest level, concurrent executions are represented by entities called processes and threads, covered in Chapter 2, Concurrency on the JVM and the Java Memory Model. Processes and threads traditionally use entities such as locks and monitors to order parts of their execution. Establishing an order between the threads ensures that the memory modifications done by one thread are visible to a thread that executes later.

Often, expressing concurrent programs using threads and locks is cumbersome. More complex concurrent facilities have been developed to address this, such as communication channels, concurrent collections, barriers, countdown latches, and thread pools. These facilities are designed to more easily express specific concurrent programming patterns, and some of them are covered in Chapter 3, Traditional Building Blocks of Concurrency.

Traditional concurrency is relatively low-level and prone to various kinds of errors, such as deadlocks, starvations, data races, and race conditions. You will usually not use low-level concurrency primitives when writing concurrent Scala programs. Still, a basic knowledge of low-level concurrent programming will prove invaluable in understanding high-level concurrency concepts later.

Modern concurrency paradigms

Modern concurrency paradigms are more advanced than traditional approaches to concurrency. Here, the crucial difference lies in the fact that a high-level concurrency framework expresses which goal to achieve, rather than how to achieve that goal.

In practice, the difference between low-level and high-level concurrency is less clear, and different concurrency frameworks form a continuum rather than two distinct groups. Still, recent developments in concurrent programming show a bias towards declarative and functional programming styles.

As we will see in Chapter 2, Concurrency on the JVM and the Java Memory Model, computing a value concurrently requires creating a thread with a custom run method, invoking the start method, waiting until the thread completes, and then inspecting specific memory locations to read the result. Here, what we really want to say is compute some value concurrently, and inform me when you are done. Furthermore, we would prefer to use a programming model that abstracts over the coordination details of the concurrent computation, to treat the result of the computation as if we already have it, rather than having to wait for it and then reading it from the memory. Asynchronous programming using futures is a paradigm designed to specifically support these kinds of statements, as we will learn in Chapter 4, Asynchronous Programming with Futures and Promises. Similarly, reactive programming using event streams aims to declaratively express concurrent computations that produce many values, as we will see in Chapter 6, Concurrent Programming with Reactive Extensions.

The declarative programming style is increasingly common in sequential programming too. Languages such as Python, Haskell, Ruby, and Scala express operations on their collections in terms of functional operators and allow statements such as filter all negative integers from this collection. This statement expresses a goal rather than the underlying implementation, allowing to it easy to parallelize such an operation behind the scene. Chapter 5, Data-Parallel Collections, describes the data-parallel collections framework available in Scala, which is designed to accelerate collection operations using multicores.

Another trend seen in high-level concurrency frameworks is specialization towards specific tasks. Software transactional memory technology is specifically designed to express memory transactions and does not deal with how to start concurrent executions at all. A memory transaction is a sequence of memory operations that appear as if they either execute all at once or do not execute at all. This is similar to the concept of database transactions. The advantage of using memory transactions is that this avoids a lot of errors typically associated with low-level concurrency. Chapter 7, Software Transactional Memory, explains software transactional memory in detail.

Finally, some high-level concurrency frameworks aim to transparently provide distributed programming support as well. This is especially true for data-parallel frameworks and message-passing concurrency frameworks, such as the actors described in Chapter 8, Actors.


The advantages of Scala

Although Scala is still a language on the rise, it has yet to receive the wide-scale adoption of a language such as Java; nonetheless its support for concurrent programming is rich and powerful. Concurrency frameworks for nearly all the different styles of concurrent programming exist in the Scala ecosystem and are being actively developed. Throughout its development, Scala has pushed the boundaries when it comes to providing modern, high-level application programming interfaces or APIs for concurrent programming. There are many reasons for this.

The primary reason that so many modern concurrency frameworks have found their way into Scala is its inherent syntactic flexibility. Thanks to features such as first-class functions, byname parameters, type inference, and pattern matching explained in the following sections, it is possible to define APIs that look as if they are built-in language features.

Such APIs emulate various programming models as embedded domain-specific languages, with Scala serving as a host language: actors, software transactional memory, and futures are examples of APIs that look like they are basic language features when they are in fact implemented as libraries. On one hand, Scala avoids the need for developing a new language for each new concurrent programming model and serves as a rich nesting ground for modern concurrency frameworks. On the other hand, lifting the syntactic burden present in many other languages attracts more users.

The second reason Scala has pushed ahead lies in the fact that it is a safe language. Automatic garbage collection, automatic bound checks, and the lack of pointer arithmetic helps to avoid problems such as memory leaks, buffer overflows, and other memory errors. Similarly, static type safety eliminates a lot of programming errors at an early stage. When it comes to concurrent programming, which is in itself prone to various kinds of concurrency errors, having one less thing to worry about can make a world of difference.

The third important reason is interoperability. Scala programs are compiled into Java bytecode, so the resulting executable code runs on top of the Java Virtual Machine (JVM). This means that Scala programs can seamlessly use existing Java libraries, and interact with Java's rich ecosystem. Often, transitioning to a different language is a painful process. In the case of Scala, a transition from a language such as Java can proceed gradually and is much easier. This is one of the reasons for its growing adoption, and also a reason why some Java-compatible frameworks choose Scala as their implementation language.

Importantly, the fact that Scala runs on the JVM implies that Scala programs are portable across a range of different platforms. Not only that, but the JVM has well-defined threading and memory models, which are guaranteed to work in the same way on different computers. While portability is important for the consistent semantics of sequential programs, it is even more important when it comes to concurrent computing.

Having seen some of Scala's advantages for concurrent programming, we are now ready to study the language features relevant for this book.



This book assumes a basic familiarity with sequential programming. While we advise readers to get acquainted with the Scala programming language, an understanding of a similar language, such as Java or C#, should be sufficient for this book. A basic familiarity with concepts in object-oriented programming, such as classes, objects, and interfaces, is helpful. Similarly, a basic understanding of functional programming principles, such as first-class functions, purity, and type-polymorphism are beneficial in understanding this book but are not a strict prerequisite.

Execution of a Scala program

To better understand the execution model of Scala programs, let's consider a simple program that uses the square method to compute the square value of the number 5, and then prints the result to the standard output:

object SquareOf5 extends App { 
  def square(x: Int): Int = x * x 
  val s = square(5) 
  println(s"Result: $s") 

We can run this program using the Simple Build Tool (SBT), as described in the Preface. When a Scala program runs, the JVM runtime allocates the memory required for the program. Here, we consider two important memory regions--the call stack and the object heap. The call stack is a region of memory in which the program stores information about the local variables and parameters of the currently executed methods. The object heap is a region of memory in which objects are allocated by the program. To understand the difference between the two regions, we consider a simplified scenario of this program's execution.

First, in figure 1, the program allocates an entry to the call stack for the local variable s. Then, it calls the square method in figure 2 to compute the value for the local variable s. The program places the value 5 on the call stack, which serves as the value for the x parameter. It also reserves a stack entry for the return value of the method. At this point, the program can execute the square method, so it multiplies the x parameter by itself, and places the return value 25 on the stack in figure 3. This is shown in the first row in the following illustration:

After the square method returns the result, the result 25 is copied into the stack entry for the local variable s, as shown in figure 4. Now, the program must create the string for the println statement. In Scala, strings are represented as object instances of the String class, so the program allocates a new String object to the object heap, as illustrated in figure 5. Finally, in figure 6, the program stores the reference to the newly allocated object into the stack entry x, and calls the println method.

Although this demonstration is greatly simplified, it shows the basic execution model for Scala programs. In Chapter 2, Concurrency on the JVM and the Java Memory Model, we will learn that each thread of execution maintains a separate call stack, and that threads mainly communicate by modifying the object heap. We will learn that the disparity between the state of the heap and the local call stack is frequently responsible for certain kinds of error in concurrent programs.

Having seen an example of how Scala programs are typically executed, we now proceed to an overview of Scala features that are essential to understand the contents of this book.

A Scala primer

In this section, we present a short overview of the Scala programming language features that are used in the examples in this book. This is a quick and cursory glance through the basics of Scala. Note that this section is not meant to be a complete introduction to Scala. This is to remind you about some of the language's features, and contrast them with similar languages that might be familiar to you. If you would like to learn more about Scala, refer to some of the books referred to in the Summary of this chapter.

A Printer class, which takes a greeting parameter and has two methods named printMessage and printNumber, is declared as follows:

class Printer(val greeting: String) { 
  def printMessage(): Unit = println(greeting + "!") 
  def printNumber(x: Int): Unit = { 
    println("Number: " + x) 

In the preceding code, the printMessage method does not take any arguments and contains a single println statement. The printNumber method takes a single argument x of the Int type. Neither method returns a value, which is denoted by the Unit type.

We instantiate the class and call its methods as follows:

val printy = new Printer("Hi") 

Scala allows the declaration of singleton objects. This is like declaring a class and instantiating its single instance at the same time. We saw the SquareOf5 singleton object earlier, which was used to declare a simple Scala program. The following singleton object, named Test, declares a single Pi field and initializes it with the value 3.14:

object Test { 
  val Pi = 3.14 

While classes in similar languages extend entities that are called interfaces, Scala classes can extend traits. Scala's traits allow declaring both concrete fields and method implementations. In the following example, we declare the Logging trait, which outputs a custom error and warning messages using the abstract log method, and then mix the trait into the PrintLogging class:

trait Logging { 
  def log(s: String): Unit 
  def warn(s: String) = log("WARN: " + s) 
  def error(s: String) = log("ERROR: " + s) 
class PrintLogging extends Logging { 
  def log(s: String) = println(s) 

Classes can have type parameters. The following generic Pair class takes two type parameters, P and Q, which determines the types of its arguments, named first and second:

class Pair[P, Q](val first: P, val second: Q) 

Scala has support for first-class function objects, also called lambdas. In the following code snippet, we declare a twice lambda, which multiplies its argument by two:

val twice: Int => Int = (x: Int) => x * 2 


Downloading the example code:

You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

In the preceding code, the (x: Int) part is the argument to the lambda, and x * 2 is its body. The => symbol must be placed between the arguments and the body of the lambda. The same => symbol is also used to express the type of the lambda, which is Int => Int, pronounced as Int to Int. In the preceding example, we can omit the type annotation Int => Int, and the compiler will infer the type of the twice lambda automatically, as shown in the following code:

val twice = (x: Int) => x * 2 

Alternatively, we can omit the type annotation in the lambda declaration and arrive at a more convenient syntax, as follows:

val twice: Int => Int = x => x * 2 

Finally, whenever the argument to the lambda appears only once in the body of the lambda, Scala allows a more convenient syntax, as follows:

val twice: Int => Int = _ * 2 

First-class functions allow manipulating blocks of code as if they were first-class values. They allow a more lightweight and concise syntax. In the following example, we use byname parameters to declare a runTwice method, which runs the specified block of code body twice:

def runTwice(body: =>Unit) = { 

A byname parameter is formed by putting the => annotation before the type. Whenever the runTwice method references the body argument, the expression is re-evaluated, as shown in the following snippet:

runTwice { // this will print Hello twice 

Scala for expressions are a convenient way to traverse and transform collections. The following for loop prints the numbers in the range from 0 until 10; where 10 is not included in the range:

for (i <- 0 until 10) println(i) 

In the preceding code, the range is created with the expression 0 until 10; this is equivalent to the expression 0.until(10), which calls the method until on the value 0. In Scala, the dot notation can sometimes be dropped when invoking methods on objects.

Every for loop is equivalent to a foreach call. The preceding for loop is translated by the Scala compiler to the following expression:

(0 until 10).foreach(i => println(i)) 

  For-comprehensions are used to transform data. The following for-comprehension transforms all the numbers from 0 until 10 by multiplying them by -1:

val negatives = for (i <- 0 until 10) yield -i 

The negatives value contains negative numbers from 0 until -10. This for-comprehension is equivalent to the following map call:

val negatives = (0 until 10).map(i => -1 * i) 

It is also possible to transform data from multiple inputs. The following for-comprehension creates all pairs of integers between 0 and 4:

val pairs = for (x <- 0 until 4; y <- 0 until 4) yield (x, y) 

The preceding for-comprehension is equivalent to the following expression:

val pairs = (0 until 4).flatMap(x => (0 until 4).map(y => (x, y))) 

We can nest an arbitrary number of generator expressions in a for-comprehension. The Scala compiler will transform them into a sequence of nested flatMap calls, followed by a map call at the deepest level.

Commonly used Scala collections include sequences, denoted by the Seq[T] type; maps, denoted by the Map[K, V] type; and sets, denoted by the Set[T] type. In the following code, we create a sequence of strings:

val messages: Seq[String] = Seq("Hello", "World.", "!") 

Throughout this book, we rely heavily on the string interpolation feature. Normally, Scala strings are formed with double quotation marks. Interpolated strings are preceded with an s character, and can contain $ symbols with arbitrary identifiers resolved from the enclosing scope, as shown in the following example:

val magic = 7 
val myMagicNumber = s"My magic number is $magic" 

Pattern matching is another important Scala feature. For readers with Java, C#, or C background, a good way to describe it is to say that Scala's match statement is like the switch statement on steroids. The match statement can decompose arbitrary datatypes and allows you to express different cases in the program concisely.

In the following example, we declare a Map collection, named successors, used to map integers to their immediate successors. We then call the get method to obtain the successor of the number 5. The get method returns an object with the Option[Int] type, which may be implemented either with the Some class, indicating that the number 5 exists in the map, or the None class, indicating that the number 5 is not a key in the map. Pattern matching on the Option object allows proceeding casewise, as shown in the following code snippet:

val successors = Map(1 -> 2, 2 -> 3, 3 -> 4) 
successors.get(5) match { 
  case Some(n) => println(s"Successor is: $n") 
  case None    => println("Could not find successor.") 

In Scala, most operators can be overloaded. Operator overloading is no different from declaring a method. In the following code snippet, we declare a Position class with a + operator:

class Position(val x: Int, val y: Int) { 
  def +(that: Position) = new Position(x + that.x, y + that.y) 

Finally, Scala allows defining package objects to store top-level method and value definitions for a given package. In the following code snippet, we declare the package object for the org.learningconcurrency package. We implement the top level log method, which outputs a given string and the current thread name:

package org 
package object learningconcurrency { 
  def log(msg: String): Unit = 
    println(s"${Thread.currentThread.getName}: $msg") 

We will use the log method in the examples throughout this book to trace how concurrent programs are executed.

This concludes our quick overview of important Scala features. If you would like to obtain a deeper knowledge about any of these language constructs, we suggest that you check out one of the introductory books on sequential programming in Scala.


Overview of new features in Scala 2.12

At the time of writing, the next planned release of the language is Scala 2.12. From the user and API perspective, Scala 2.12 does not introduce new ground-breaking features. The goal of the 2.12 release is to improve code optimization and make Scala compliant with the Java 8 runtime. Since Scala's primary target is the Java runtime, making Scala compliant with Java 8 runtime will reduce the size of compiled programs and JAR files, better performance and faster compilation. From the user perspective, the major change is that you will have to install the JDK 8 framework instead of JDK 7.

The particular changes in Scala 2.12 worth mentioning are the following:

  • In previous versions, traits compiled to a single interface if all of their methods were abstract. If the trait had a concrete method implementation, the compiler generated two class files--one containing the JVM interface, and another class file containing the implementations of the concrete methods. In Scala 2.12, the compiler will generate a single interface file containing the Java 8 default methods. The net effect is reduced code size.

  • Previously, each Scala closure was compiled into a separate class. Starting with 2.12, Scala closures are compiled into Java 8-style lambdas. The consequence is reduced code size and potentially better optimizations by the Java 8 runtime.

  • Scala compiles into Java bytecodes, which are then interpreted on the Java Virtual Machine. In Scala 2.12, the old compiler backend is replaced with a new implementation that generates bytecode more quickly with a positive impact on compilation speed.

  • Scala 2.12 comes with a new optimizer, which is enabled with the -opt compiler flag. The new optimizer is more aggressive at inlining final methods, does better escape analysis for objects and functions that are created and used in a single method, and does dead code elimination. All this has a positive impact on the performance of Scala programs.

  • Scala 2.12 allows using lambdas for Single Abstract Method (SAM) types. SAM types are classes or traits that have exactly one abstract method, which is normally implemented by extending the class. Assume that we have a method invocation with an argument whose expected type is a SAM type. If the user passes a lambda, that is, a function literal, instead of a SAM type instance, the 2.12 compiler will automatically convert the function object into an instance of the SAM type.



In this chapter, we studied what concurrent programming is and why Scala is a good language for concurrency. We gave a brief overview of what you will learn in this book, and how the book is organized. Finally, we stated some Scala preliminaries necessary for understanding the various concurrency topics in the subsequent chapters. If you would like to learn more about sequential Scala programming, we suggest that you read the book, Programming in Scala, Martin Odersky, Lex Spoon, and Bill Venners, Artima Inc.

In the next chapter, we will start with the fundamentals of concurrent programming on the JVM. We will introduce the basic concepts in concurrent programming, present the low-level concurrency utilities available on the JVM, and learn about the Java Memory Model.



The following exercises are designed to test your knowledge of the Scala programming language. They cover the content presented in this chapter, along with some additional Scala features. The last two exercises contrast the difference between concurrent and distributed programming, as defined in this chapter. You should solve them by sketching out a pseudocode solution, rather than a complete Scala program.

  1. Implement a compose  method with the following signature:

                def compose[A, B, C]
                (g: B => C, f: A => B): A => C = ??? 

    This method must return a function h, which is the composition of the functions f and g

  2. Implement a fuse method with the following signature:

                def fuse[A, B] 
                (a: Option[A], b: Option[B]): Option[(A, B)] = ??? 

    The resulting Option object should contain a tuple of values from the Option objects a and b, given that both a and b are non-empty. Use for-comprehensions

  3. Implement a check method, which takes a set of values of type T and a function of type T => Boolean:

                def check[T](xs: Seq[T])(pred: T => Boolean): Boolean = ??? 

    The method must return true if and only if the pred function returns true for all the values in xs without throwing an exception. Use the check method as follows:

                check(0 until 10)(40 / _ > 0) 


    The check method has a curried definition: instead of just one parameter list, it has two of them. Curried definitions allow a nicer syntax when calling the function, but are otherwise semantically equivalent to single-parameter list definitions.

  4. Modify the Pair class from this chapter so that it can be used in a pattern match.


    If you haven't already done so, familiarize yourself with pattern matching in Scala.

  5. Implement a permutations function, which, given a string, returns a sequence of strings that are lexicographic permutations of the input string:

                def permutations(x: String): Seq[String]  
  6. Implement a combinations function that, given a sequence of elements, produces an iterator over all possible combinations of length n. A combination is a way of selecting elements from the collection so that every element is selected once, and the order of elements does not matter. For example, given a collection Seq(1, 4, 9, 16), combinations of length 2 are Seq(1, 4), Seq(1, 9), Seq(1, 16), Seq(4, 9), Seq(4, 16), and Seq(9, 16). The combinations function has the following signature:

                def combinations(n: Int, xs: Seq[Int]): Iterator[Seq[Int]] 

    See the Iterator API in the standard library documentation

  7. Implement a method that takes a regular expression, and returns a partial function from a string to lists of matches within that string:

                def matcher   (regex: String): PartialFunction[String,   

    The partial function should not be defined if there are no matches within the argument strings. Otherwise, it should use the regular expression to output the list of matches.

  8. Consider that you and three of your colleagues working in an office divided into cubicles. You cannot see each other, and you are not allowed to verbally communicate, as that might disturb other workers. Instead, you can throw pieces of paper with short messages at each other. Since you are confined in a cubicle, neither of you can tell if the message has reached its destination. At any point, you or one of your colleagues may be called to the boss's office and kept there indefinitely. Design an algorithm in which you and your colleagues can decide when to meet at the local bar. With the exception of the one among you who was called to the boss's office, all of you have to decide on the same time. What if some of the paper pieces can arbitrarily miss the target cubicle?

  9. Imagine that, in the previous exercise, you and your colleagues also have a whiteboard in the hall next to the office. Each one of you can occasionally pass through the hall and write something on the whiteboard, but there is no guarantee that either of you will be in the hall at the same time.

Solve the problem from the previous exercise, this time using the whiteboard.

About the Author

  • Aleksandar Prokopec

    Aleksandar Prokopec, who also authored the first edition of this book, is a concurrent and distributed programming researcher. He holds a PhD in computer science from the École Polytechnique Fédérale de Lausanne, Switzerland. He has worked at Google and is currently a principal researcher at Oracle Labs.

    As a member of the Scala team at EPFL, Aleksandar actively contributed to the Scala programming language, and he has worked on programming abstractions for concurrency, data-parallel programming support, and concurrent data structures for Scala. He created the Scala Parallel Collections framework, which is a library for high-level data-parallel programming in Scala, and participated in working groups for Scala concurrency libraries, such as Futures, Promises, and ScalaSTM. Aleksandar is the primary author of the reactor programming model for distributed computing.

    Browse publications by this author

Latest Reviews

(2 reviews total)
High quality information presented with good structure.
Great content, well presented.

Recommended For You

Book Title
Unlock this full book with a FREE 10-day trial
Start Free Trial