200On Learning Concurrency

Author: Dr. Heinz M. KabutzDate: 2012-03-26Java Version: NoneCategory: Inspirational

Abstract: Every Java programmer I have met knows that they should know more about concurrency. But it is a topic that is quite hard to learn. In this newsletter I give some tips on how you can become proficient in concurrency.

Welcome to the 200th issue of The Java(tm) Specialists' Newsletter! Thank you for your amazing support. It has been fun. As a token of appreciation, I am presenting a gratis three-hour online workshop on Thursday 29th March 2012 from 6-9pm GMT. Topic is Avoiding Liveness Hazards, which incidentally was also the topic of my first newsletter. In the first 1.5 hours I will lecture on the subject and then it will be up to you to find liveness hazards in some example code using the techniques presented. We will also have some time for questions and discussions. [Update: Since that webinar is obviously over now, I'd like to invite you to instead check out Heinz's Happy Hour, a free webinar series happening every first Thursday of the month.]

I had the privilege of being invited to speak at the codemotion conference in Spain on the weekend, which was also broadcast in Rome. I expected to see about 150 people, but it was completely packed with over 1000 attendees. That is a very good turnout for a first programming conference. Well done to David Gomez Garcia who organized the event in Madrid.

One of my hobbies is food. When I was a child, I wanted to own a restaurant. I built my own little taverna underneath a palm tree in our garden, where my poor family was treated to the most horrible meals, which they pretended to enjoy. As a child, I frequently had stomach problems, maybe as a result of my passion with food. Every time my mother took me to the doctor, she complained about how expensive he was. I quickly changed my career prospects to doctor and told everybody "because then I can help people". Fortunately I discovered the joys of programming in my teens and a hobby became my career.

Madrid is a place to visit if you like good food. I had one of my best steaks ever at the Casa Paco. Despite what the reviews say, prices are reasonable for what you are getting. I did not get suckered into trying their various starters, since there are better places for tapas. The meat was old ox, very tender and with lots of flavour. I think I would have done a better job of grilling it, but the quality of meat made up for it. I also had a fantastic Mexican meal at the Taqueria del Alamillo with my friend and Java Specialist instructor for Latin America, Alvaro Hernandez. We decided to go there on the spur of the moment and were very lucky to get a table after a long wait. Great food, but I would have preferred it a bit more spicy.

javaspecialists.teachable.com: Please visit our new self-study course catalog to see how you can upskill your Java knowledge.

On Learning Concurrency

"Hi, I'm Anton." A large red-haired fellow shook my hand at the special maths 106 class for gifted students. In the previous year, half the class had failed and the University of Cape Town had considered cancelling this course. You were only allowed to take the class if you had achieved a high maths mark in high school. Since this was a small class, there were only three students with the exact same selection of classes: Anton de Swardt, John Green and myself. I had taken the special maths class because I was under the illusion that I was quite smart in the subject, after coming 11th in the maths olympiad of Cape Town, a city or three million people. Boy was I in for a shock. I scraped through the subject, whilst John got 99%.

From then onwards, the three of us were inseparable. Whenever there was a group project to be done in computer science, it was at least John, Anton and Heinz, with the occasional addition of another of our friends, Zach. John managed to get the class medal for computer science three years in a row, the only person to ever manage that. He always beat Anton and me in tests and exams. To say that he is a genius is not giving him enough credit. After all, he came second in all the schools of his race, despite having to stay at home for the entire grade 10 due to rioting. The 80s in South Africa were tumultuous. Thus super-genius John always had better marks than me, except one single time.

Of all the modules that I chose, the one that I found the most interesting was on parallel and distributed computing. For some reason, I took to the course like a duck to water. John took the same course and was hardly seen in class, having also signed up for a bunch of additional extramural activities, such as organizing the university choir and learning ballroom dancing. When the big day of the exam came, I was extremely well prepared like a well-oiled machine. John had barely opened the book. We wrote the exam and afterwards John asked me which two questions I had decided to answer. We were supposed to answer three of the given four questions. Accidentally, John had misread the instructions and had only answered two! He ended up with 65% and I with 96%. It was the only shot I had at beating him academically and at the same time was John's worst mark of his entire university career.

Parallel and concurrent programming is something that every Java programmer realizes that they should know more about. Talks on multi-threading are always well attended at conferences. Threading was usually the subject where programmers lost points in the Java Programmer Certification. When I wrote the Java 5 certification, I also lost a point for threading, which I mentioned in newsletter 120. But it was not my fault. The question had a mistake in it and there was no correct answer. After I mentioned this in my newsletter, someone from Sun Microsystems found the question and removed it from the examination. Thus even the inventors of Java made mistakes with this tricky subject.

As I said already, every Java programmer I speak to is aware that they need to know more about concurrency. Even if they are not always exposed to the innards due to the frameworks they are using, the beast of concurrency still leaks through. It might raise its ugly head due to their systems not scaling due to contention or they could see deadlocks or race conditions.

Last Friday I gave a deadlock problem to two groups of Java programmers to solve. Most of them immediately started snooping around in the source code. The exercise consisted of 15000 lines of ugly Java code. With a bit of luck, they could possibly find the problem in a couple of hours. However, if it were 15 million lines of code, then there would be no chance at all of discovering the deadlock by trawling through the source. The correct approach would have been to look at the stack trace and check what the threads were up to. By process of elimination, they would pretty quickly find three or four candidates and the stack trace would then have taken them to the exact line of code that was at fault.

I heard about a project where over 1000 methods were marked as synchronized. Did they really need that many methods to be single-threaded? Some of the methods were 2000 lines long. Safety is important, but marking all your methods as synchronized could lead to deadlocks and poor performance. I am sure that the programmers had good intentions. They might even have read a tutorial or a book on the subject. Knowing just a little bit can be more dangerous than knowing nothing at all.

So how did I learn about Java concurrency? First off, I had the privilege of getting a good foundation in distributed and parallel programming with Prof Ken MacGregor at the University of Cape Town. This was further expanded on with a PhD on analysing the performance of communicating concurrent systems. As those with a PhD know, the degree is more about persistence than brains. Also, the information I learned and discovered was not that useful for real world Java programs. Again, this is typical of a post-graduate degree. My education at university was thus a small help, but I would have also learned threading without that.

I started coding Java in 1997 and a lot of the work I did involved threading. I coded several concurrency bugs in my program. Usually we learn best by making mistakes. Fortunately none of my errors caused a serious loss of income for my company. I did manage to write race conditions and deadlocks, sometimes in the most unusual way.

In 1999 I wrote my first Sun Java Programmer Certification. To prepare myself, I studied threading in far more detail and realized that a lot of my understanding was incorrect. Certifications are useful in that they highlight the areas where we need to pay more attention.

In 2000, I studied both the Java Virtual Machine Specification [ISBN 0201432943] and Doug Lea's Concurrent Programming in Java [ISBN 0201310090] . Both books explained a lot about the inner workings of Java. They are a bit dated by now, but lay a good foundation. The key verb here is "studied" rather than "read". It is never enough to simply "read" a book, you have to internalize it by working through it carefully and spending time trying out the code examples and possibly coming up with better ones.

By the time Java Concurrency in Practice was released in 2006, I was already well versed in the subject matter, which is why I had the honour of being allowed to review the book prior to publication. What I like about Goetz's book is that it covers the essentials of concurrency that every Java programmer needs to know. As Brian points out, concurrency is not some "advanced subject" that you can avoid learning about. Every Java programmer should understand threading.

I have a confession to make. I have never been on a Java course. I almost went once in early 1998, but then decided at the last moment that I probably knew more than the instructor. Arrogant, I know. It was true though. My colleagues afterwards told me that the instructor did not know the difference between notify() and notifyAll(). In the meantime, we were using that in production code. I learned later through Doug Lea's book that our production code had in fact been incorrect, but it did work for many years until another team found some serious errors in it. We had been lucky. However, we would not have learned of our errors from that course, since the instructor also did not know. Having a well-trained and knowledgeable instructor is what you are paying for in a course.

I spent about twenty weeks in the last twelve months studying Java Concurrency in Practice in great detail to produce my Concurrency Specialist Course, which evolved into my Extreme Java - Concurrency Performance Course. When you write a course on such a complicated subject, you need to make sure that everything you write is correct. This means running your own experiments to verify that you see the same results. Sometimes new Java versions caused differences in behaviour. At other times there were better, more efficient approaches. Also, I wanted to use all the latest Java 7 utilities, such as Phaser and Fork/Join.

Another thing I did was join the Concurrency Interest Mailing List. This contains a lot of clever questions and allowed me to bounce a few of my ideas to the best brains in the industry. It's a list that is worthwhile joining, even just as an observer.

Here are some tips to follow if you would like to learn concurrency:

1. Recognize that concurrency is a topic that you should understand. Despite the excellent frameworks such as Akka now available for Java, you should still understand what is going on.
2. Get hold of some good books on the subject and study them. Spend at least 40 hours per chapter, trying out all the code examples and making sure that you understand everything.
3. Start writing some threaded code and try it out on lots of different hardware. Remember that if it works on your machine, you might have just been lucky.
4. Join the concurrency interest mailing list and read their archives. Try to just observe for the first few months.

It is not necessary to attend a course. I didn't. However, it does save you a lot of time and is a lot easier than trying to figure out everything yourself. But if you have lots of free time, then Goetz's book, coupled with the other resources I mentioned, will be enough to help you understand concurrency. If you do not have a lot of free time or would like a guide to take you on this fascinating journey, then please make sure that the guide understands the difference between notify() and notifyAll() :-)

Kind regards from Crete

Heinz

Comments

We are always happy to receive comments from our readers. Feel free to send me a comment via email or discuss the newsletter in our JavaSpecialists Slack Channel (Get an invite here)

Related Articles

Browse the Newsletter Archive