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 is about dealing with lots of things at once.
Parallelism is about doing lots of things at once.
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.
- java.util.concurrent packages provides utility data structures and functions to support concurrent and parallel programming (Package java.util.concurrent)
- 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.
Reducer in Closure
Closure’s reducer can provide the benefit of concurrent execution (for map-reduce type ones) along with functional simplicity.
There’re a lot of large-scale system topics lately. The distributed query system Presto may be one example. Or, New Relic’s Rubicon project (New Relic Analytics Aims to Speed IT Problem Solving) are another interesting project as large scale query services.
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.
The cloud platform like AWS and OpenStack are gaining popularity these days, and I came up with my mind to take time to study on them. The followings are some notes of my first trials.
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.
It’s nice to have default built-in chef recipes, but it’s still limited ones yet (also, issues and pull requests seems stacking up).
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.
Then I’m switching to the aws plugin for vagrant. It nicely starts up EC2 instances through standard vagrant CLI commands, as similar way as local virtual machines.
The above site nicely describes the process to setup git server on AWS. Along with the “berkshelf” gem which manages cookbooks, it seems to allow more flexibly setup of chef environment. Nice.
Just playing around future (Futures and promises From Wikipedia), inspired by scala learning and the above library (eproxus/future).
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.
mix run -e "SampleFuture.run" [9227465, 14930352, 24157817, 39088169] 4.438063 [9227465, 14930352, 24157817, 39088169] 7.567721
Pushed by the recent buzz, I just started learning around OpenStack.
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.
Nice keynote to demonstrate how OpenStack can work in production. The infrastructure can grow without service interruptions. Canonical and Ubuntu seems gaining presence on these cloud-based solutions.
The keynote from the Rackspace. The [OpenStack Code Commits] graph (at around 7:10) is interesting, which indicates a variety of companies are taking initiative.
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.