Review of Venkat Subramaniam's new book on Concurrency

Programming Concurrency on the JVM: Mastering Synchronization, STM and Actors
by Venkat Subramaniam

This book should be considered part of a two book series along with Venkat’s 2009 book “Programming Scala: Tackle Multi-core Complexity on the JVM”. The earlier book was a relatively short (250 pages versus 852 pages for Odersky’s Scala book), perhaps too short, overview of Scala. It’s 12 chapters skip over lots of the details in Odersky’s 18 chapter book, and contains only a single chapter on Concurrent Programming.

By comparison the new book is all about Concurrent Programming models and attempts to be agnostic about the JVM language to be used. Most examples are first given in Java, then a simpler way is shown to do it in Scala, and then often a short section saying how the example could be done in Ruby.

The book describes the difficulties of concurrent programming in JVM languages especially given the rise of multi-core processors. It then describes three “solutions”: the naïve Java approach, Software Transactional Memory and Actors. It should be noted that the Actors chapter is based on Akka, so if you don’t care for Akka you may not like this book.

The Power and Perils of Concurrency – This should be an unsurprising recap of well known problems; if you’re reading this book you will almost certainly have run into the problems listed here already.

Strategies for Concurrency – Talks about ways to divide problems into parts that can be computed independently

Modern Java/JDK Concurrency – This talks in detail about the changes made to the Java libraries to better support concurrency, specifically things like using ExecutorService rather than “new Thread()” and using Lock vs. synchronized. Interestingly though the chapter fails to discuss the little known but serious differences between synchronized blocks and methods involving fairness and barging.
Taming Shared Mutability – This chapter begins to offer the Scala kool-aid of mutability is bad. Reading this chapter is made easier if you’ve already read Goetz’s “Programming Concurrency”.

Software Transactional Memory – This chapter talks about Clojure’s STM model and how to use it in Java via Akka. Its an interesting chapter but one that will feel odd if you’re a programmer also coming to terms with non-relational databases. As databases move away from the transitional transactional model here comes STM bringing transactions to mutable variables.

Actor-based Concurrency – Actors are basically a message passing schema where immutable messages are passed between lightweight actors (thread-like). Just as you can use thread pools to reduce the cost of threads there are what amount to actor pools which lighten their cost. It does require some rethinking to embrace the actor approach.

Overall this is a fine book that brings quite a lot to the table. My only reservation would be that if you are a seasoned Java programmer you might take the first four sections as a given and jump right to the Actors approach. And if you’re not a seasoned Java programmer you probably don’t realize how badly you need this book.

Books on Scala

While the best way to learn a new language is to write in it there is still a great value to reading books on the language. When I was a C/C++ coder (a long time ago) I made it a point to read every book published on the language. The benefit of picking up even a single tip on how to use the language I spent 10 or more hours a day in was simply too large to ignore.

So, I decided to look at the current set of books on Scala. If you don't know Scala it is a hybrid OO/Functional JVM language.

Here are the books I found that are either in print or soon to be in print.

Title	Author	Length	Publication Date or Amazon Rating
Programming In Scala	Odersky	852 pages	4.5 stars
Programming Scala	Wampler	448 pages	4.5 stars
Programming Scala	Subramanian	250 pages	4.0 stars
Beginning Scala	Pollak	320 pages	3.5 stars
Scala In Action	Raychaudhuri	525 pages	(fall 2011 9 of 14 chapters available)
Scala In Depth	Suereth	225 pages	(Winter 2011 8 of 11 chapters available)

While book length is not a good predictor of quality its hard to see how you can cover a language like Scala in a short book. In particular "Scala In Depth" looks to be the shortest book!

Personally my approach to learning Scala was to put Subramanian's book on my right, Odersky's book on my right, and a Scala console in the middle. I then read the same chapter in each book, working through each and every example in the Scala console. This way I got the benefit of learning the same concept via the different wording of two top authors...and I forced myself to actually write some Scala.

For my next Scala reading I'll try Scala In Action simply based on past enjoyment of the "X In Action" books from Manning Press. None of them have ever let me down.

I should also mention two other related books:

"Seven Languages In Seven Weeks" by Bruce Tate (full disclosure: I'm interviewed in the book's chapter on Prolog)
and
"Programming Concurrency on the JVM" by Subramanian. While not strictly a Scala book it is still very interesting as it introduces Software Transactional Memory and Actors and shows how to use them in various jvm languages.

The most basic failure

In this holiday buying season the Kindle and the Nook continue to be very popular, and the battle still ranges over the viability of dedicated e-readers versus general purpose devices like the IPad.

Poor Sony.

I own one of the Sony E-Readers and quite like it. It has many advantages over the Kindle, Nook or IPad and yet its largely forgotten. I have a theory as to why.

Sony forgot to give its product a name! Quick test: what is the name of Sony's e-reader? Its "E-Reader". Since thats also the generic term for the device it amounts to not having a name.

Sometimes having the generic name for the device is a good thing. Xerox has the generic name for the photocopier. The important thing however is the timing.

Its a Good Thing to have your product name become the generic name. Its a Bad Thing however to simply use an existing generic name.

Imagine a device making introducing an MP3 player and calling it "MP3-Player". Rather than subsuming all the good will associated with the general product this new device would feel like a cut-rate generic device.

I think thats what happened to Sony's device. You can't even talk about their reader. I can't tell you how many times people have asked me: "is that a Kindle?". I say "no, its Sony's Kindle", which is certainly not an answer to warm the hearts of Sony's marketing department.

I don't know what surprises me more, the fact that Sony forgot to name their device, or that no one seems to have noticed this failure.

Guest Blog over at RubyLearning.com

I am the guest blogger over at RubyLearning.com this week. My article on the value of maintaining a personal bug log is at: http://rubylearning.com/blog/2010/10/25/the-value-of-a-personal-bug-log/.

Although I'm not a Ruby programmer the RubyLearning blog run occasional articles on learning in general.

Profiled for JavaOne

I was recently profiled for the upcoming Oracle JavaOne. This was because of my open source project Log4JFugue.

The link is: http://www.oracle.com/us/javaonedevelop/future-of-java-168616.html#tarbox

It was interesting to sit back and think about what makes using Java interesting. It also reminded me of the freedom that comes from having an open source project. If I want to explore using Groovy I don't need to get the approval of a committee I can just do it.

Where do you get your Intellectual Stimulation?

Most of us work in jobs that primarily focused on solving an immediate need for existing customer, who needs a quick solution today. This certainly pays the bills but generally isn't the kind of venue to leads to discussions about to create "software that sings". Indeed when I used that phrase in a previous article I got comments that even thinking about writing such software was beyond the pale for most people.

So, where do people find an outlet for that part of the mind that goes beyond solving the problem for today? Having just come back from the Atlassian Summit 2010 I can tell you how recharging it was to spend a few (long) days surrounded by people whose mission it was to be better. One of Atlassian's commitments this year is for their tools to save every developer 15 minutes a day. It was fun to spend time thinking, arguing, brainstorming about how to change tools and processes to squeeze out an incremental amount of productivity. And then I went back to work. where the focus is (as it should be) on the short term deliverable. I suspect I'm not alone in this regard and wonder how people recharge their batteries.

Some years back I visited The Orchard tea room in Cambridge, England. This humble tea room hosted Virginia Wolf, Bertrand Russell, Ludwig Wittgenstein and others. Its as if Edward Tufte, Richard Feynman and Claude Shannon hung out together at the local Starbucks. Imagine sitting at the next table from that gathering every week! Without putting myself in such company I wondered if such places existed today where motivated people could gather and discuss their craft.

Our conferences and User Group meetings try fill this role but to a very limited degree. Its tough to have an in depth discussion at a 15,000 person, $5000 JavaOne for example. User Space conferences may be better for this but they're still discrete events rather than something ongoing. I started wondering about other models such as the JavaPosse. That's a group of four friends who meet once a week or so and basically spend an hour discussing whatever they find interesting. While the Apple bashing/praising they engage in has gotten a bit tiring it’s still a very interesting model. The parts that stand out for me are:

- its a regular meeting rather than an occasional event
- it happens (mostly) in person. The four members actually sit together and talk
- it's outside the work venue and not paid for by my employer so I'm not obligated to focus on near term problems/solutions

I've decided to start a similar group myself, not with the intention of podcasting it but simply to spend some regular time talking with smart people about the craft. We currently have three members and are carefully thinking about a couple more people. We're also trying to determine what kind of meeting place we should have.

I wonder if anyone else has tried something like this or if anyone has other ideas for on-going mental stimulation?

Follow The Sun versus Chase The Sun

Follow The Sun is the management concept that by spreading your development team across the world you always have someone who is awake and can work on a problem. In the imagined perfect world Team A works on a problem for their eight hour day and then hands off the partially developed feature to the next team arriving on the next continent. The idea is based on the notion that developers and software are both fungible assets. (Fungibility is the property of a good or a commodity whose individual units are capable of mutual substitution. Examples of highly fungible commodities are crude oil, wheat, orange juice, precious metals, and currencies. Wikipedia)

Since developer A is equivalent to developer B it just make sense for them to hand off bits of partially developed code to one another. (sic)

In the real world this often becomes Chase The Sun rather than Follow The Sun. There are two variations of Chase the Sun.

In the first variation all developers are basically expected to be available for questions and support 24 hours a day. Between Skype and text messages and laptops or smart phones we often see developers basically in perpetual on-call mode. This can actually be effective...until the team burns out.

In the other variation team A makes a change that breaks the system or changes it significantly, and then goes to bed. Team B comes to work to find a broken or "different' system and spends their day doing archeology on team A's changes. Successful or not they try to warn Team C about the state of the system and the changes that they've made in an attempt to resolve the issue.

Each team leaves emails that will be read 18 hours later by the team prior to them in the earth's rotation. Besides being inefficient this variation leads to predictably negative team interactions. Its just too easy to explain each day's problems as being caused by "them".

Chase the Sun can be changed back into Follow The Sun by following a few simple rules

a) developers are not fungible

b) there is enough code that the code also isn't fungible, so not everyone will understand everything

c) geographically dispersed teams can assist each other investigations or in remote pair programming where one team develops and the other tests

d) asking geographically dispersed teams to work on the same code or features is often a recipe for disaster