Concurrency is hard but does anyone care?
I had the privilege of being interviewed by my friend Richard Sharpe of Enerjy at CodeMash back in January of 2008 regarding Java concurrency and specifically how the Java language might evolve to address concurrency. My take was (and is still) that Java is maturing and attempting to address concurrency concerns — case in point, my friend Brian Goetz does a hip job of outlining a proposed Java 7 enhancement in his series “Java theory and practice: Stick a fork in it, Part 1“. Plus, in JavaWorld’s article entitled “The future is now — Java development in 2008“, which attempted to lay the ground work for what we as an industry would most likely see evolve on the Java platform in 2008, even mentions concurrency.
Yet, with the simple truth that indeed, concurrency programming is extremely difficult (to do correctly) and more and more machines are implementing multi-core architectures, I get a dreaded feeling that nobody really cares. Granted, Brian’s book “Java Concurrency in Practice” appears to be selling well (it’s a great book, baby) but I don’t hear a lot of people talking about concurrency or how they’re planning on dealing with it. I suppose, in truth, applications don’t necessarily have to deal with new architectures and in large part, many people appear to be quite happy staying put in Java (as opposed to integrating other alternate languages, which support concurrency much more naturally).
Am I just failing to see something or is concurrency something the Java community will deal with in 2010?
| Related odds and ends | ||
|---|---|---|
Saturday 06 Sep 2008 | Dynamic Languages, Software Development
i remember blog post about how Thread and SQL packages should be deprecated and they should be. typical developer(j2ee developer) should never use threads and old school jdbc. if you do swing you should know threads. I have that Concurrency book, but i did not read it and i wont until i will really have a need to use advance threading. i think the best idea is to to use framework (like j2ee) that makes threading transparent.
The problem is that people think they don’t care, but they do. Do you write servlets? Do you use the ServletContext or HttpSession APIs? Do your servlets have instance fields? Do you write Swing apps? If so, you’re a concurrent programmer, whether you realize it or not.
EJBs impose some pretty substantial restrictions to insulate the developer from concurrency. Most developers have chosen lighter weight mechanisms (e.g., Spring), which may be easier to use than EJB in general, but which re-expose you to concurrency.
One reason people don’t realize they care is that they haven’t been burned enough. IA32 is the most popular CPU architecture these days, and it offers a stronger memory model than required by Java, so *some* of the nasties don’t actually happen there. But the trend is towards weaker memory models, so programs that have “worked” for years will start breaking as we deploy on new generations of hardware.
Exactly. I know a great deal of the work of concurrency/parallelism is handled for me by frameworks and specifications…
When I do dip into it manually for the occasionally off the beaten path stuff, I’m happy to work with my copy of CiP while keeping an eye forward to stuff like the parallel array which is pretty exciting.
From what I see, you’re right. Most developers just don’t care and it’s mainly coming out of ignorance. Concurrency is a difficult subject but I’m not sure it has anything to do with the fact that they don’t care. I think that most developers are just satisfied by concrete visual results. When developing a web application, the average developer will be satisfied with a well rendered page and a complete business process that works on *their* own machines (you know… triggering an action on screen and seeing that the actual data is persisted in the database and an email is sent, etc…). I guess concurrency is not visual and concrete enough for developers to care. Which is by no doubt stupid, as Brian mentioned, 90% of all java applications today run in multi-threaded environments.
Another thing that I’ve noticed is that people care so little, that they really believe there’s nothing to it. So when you do a code review and tell a developer that his/her code is not thread-safe, their fix is just to add synchronized to the method and as far as they’re concerned it’s fixed.
BWT, thanks Brian for the amazing book - it should be on the desk (not the bookshelf) of every java developer… hmmm… I that’s an idea
I think it’s more like they don’t realize the dangers and pitfalls there is to writing concurrent code. I think most people care, but just don’t know any better, and think that the occasional synchronized block is enough. Some people don’t use synchronized enough to get a dead-lock, and will instead have lost-update bugs in their code - these do not necessarily blow up with a bang and can therefor go unnoticed for a long time. This lack of explosions will in turn lull the developers into thinking their code is correct.
In my experience, people realize that they don’t know enough to deal with concurrency, so they try to avoid writing code where they have to deal with it directly. But they don’t realize that their lack of knowledge on concurrency actually makes it near impossible for them to write code that is devoid of the concurrency they sought to dodge.
And Brian, you should have made JCiP a hardcover - that way it would make a greater impact when I hit my collegues in the head with it.
Concurrency is hard to comprehend and to code to it.Most people blame concurrency when bad stuff happens. And as pointed out the simplest way to “fixing” a concurrency problem is to add synchronized.
People that are new to concurrency often fear it. It’s like nuclear energy! It’s powerful and wonderful but “unknown” and therefore “scary”. And trying to avoid the “beast” often leads to it’s “lair”. Most of concurrency problems I have witnessed were from people actively trying to avoid it or ignore it.
And JCiP would be of great benefit in hard cover, for throwing it at ignorant colleagues!
What Brian is saying is something that I am experiencing more and more in my performance tuning engagements. Any time you access data that is being shared with other threads/processes, you are programming concurrently. So, developers are already writing concurrent code albeit accidentally. This typically results in some very strange bugs. More over, the tools that we have today aren’t very helpful in helping to resolve these issues which makes them difficult if not impossible to resolve.
And, if you believe that your favorite application server is concurrency bug free, think again. App server projects face the same constraints that any other project does and they’ve are also finding some very nasty bugs. Bottom line, we all need to be aware of how the hardware is working and how that affects our code or how we should be coding.
[...] Concurrency programming is difficult to get right– when I mused that I was concerned “that nobody really cares”, I was pleasantly surprised by a series of comments which serve to highlight the issue at hand; that is, CPU architectures are evolving, man, and Java’s concurrency model might not fit the bill. [...]