Monthly Archives: December 2013

As part of some more trials on future, I’ve uploaded the above ExFuture module on the GitHub. The grammer is still immature, but trying to simplify it using macros. Internally, it uses spawn/receive process to asynchronously executing the specified code blocks or functions.

Basically, I’m trying to learn around the nice feature set of Scala/Akka.

The above introduction video talks about the usage of futures on scala, with an example of asynchronously hitting multiple external APIs. There’re various functional-style methods on futures, and nicely structured with Scala’s DSL framework. The above ExFuture, is just a trial to implement the similar type of functionalities.

Just read through the book. Though it’s beta release yet, major topics are covered.

It starts with a basic thread/locking mechanism (traditional dead-locking problems on shared data), and then goes through the functional programming aspects – immutable data structures, future/promise and actors (how to divide problems into small chunks, which can be executed in concurrent and parallel). This book nicely uses several languages (Java, Closure, Elixir) to capitalize the benefits of each concurrency model.

The followings are some reading notes.

Concurrency and Parallelism

Concurrency sounds understandable, but it’s a little difficult to clearly define if we consider parallelism along with it. This book describes as follows using a quote from a presentation.

Concurrency provides a way to structure a solution to solve a problem that may (but not necessarily) be parallelizable.

As indicated in the book, concurrency and parallelism concepts are often confused and sometimes inter-mixed. I’m not confident enough yet, but concurrency may be one method to scale-out the problem solving, which is often utilized by parallel executing devices/platforms.

Concurrency in Java

Java provides built-in thread and locking mechanism, but also some libraries are provided for assisting concurrency.

As indicated in “Threads and Locks” section, ConcurrentHashMap can be used to reduce the bottleneck of shared data compared with standard HashMap.

Mutable states can be hidden inside the library functions (ex. SimpleDateFormat), and even a simple code can cause conflicts in concurrent execution. It requires caution to use multi-threading.

Actors and Object-Oriented Programming

Actors are very lightweight concurrent entities, which communicates each other with message passing.

we can think of actors as the logical extension of object-oriented programming to the concurrent world. Indeed, you can think of actors as more object-oriented than objects, with stricter message passing and encapsulation.

It’s an interesting viewpoint. The method invocation corresponds to message passing. Java’s CORBA or remote method invocation used to be discussed for providing similar concept. They didn’t go mainstream, but recent buzz around concurrency and actors might go different way.

Actors are explained with Elixir sample codes. It’s underlying erlang’s model is now applied to JVM through akka, and go-lang provides similar functionality through Goroutines. This actor model would be a major driving factor for distributed system, and could be a standard programming paradigm in near future, by partially replacing the traditional thread models.

Functional programming style provides mathematical or abstract form of calculation, but recent programming languages and library functions are bringing these into the practical world. It’s interesting to see how the programming will be structured in 5 years later.

AWS OpsWorks

AWS OpsWorks is an application management service using chef as its configuration engine. It can define the layer of application on EC2 instances with some pre-configured cookbook settings, like rails and node.js servers.

OpsWorks supports loading custom cookbook too, but it’s a little cumbersome. I tried to put them on GitHub, but it requires very fixed directory structure as in the above User Guide. There’re many public cookbooks in the GitHub, but it cannot be easily applied.

If your cookbooks are fully established, this approach may work, but it might be a little difficult to take try and error approach.

It spawns the erlang process to concurrently execute the map operation for each collection element. Naive fibonacci function is used for benchmarking purpose.

In this example, parallel version works twice faster than normal one, on my MacBook Air (concurrency is four, but it’s bound by the number of CPU cores, which is two). When using less intensive calculation (ex. a function which just waits by :timer.sleep), it just works as fast as number of processes.

This video has simple and good introductory explanation. There’re many different hypervisors which provides virtual machines, and it’s getting difficult to manage them as it grows. OpenStack Shared Services are located on top of hypervisors and provides unified management interfaces.

It’s a nice Q&A session which talks about ruby history and now and futures, with funny interactions. At around 6:00, one question was what could be different if you resigning ruby now. One of the answer is about the concurrency, existing thread vs actor models. It’s interesting that many of the object-oriented languages are introducing actor based modeling features.

Ruby is equipped with Fiber for lightweight threading, but its mutable nature and performance penalties might be sometimes difficult to super-concurrent programming. Along with JRuby and Rubinius, how ruby will be going for this area may be an interesting topic to keep watching.