JDK 5.0: More Flexible, Scalable Locking

An anonymous reader writes "Multithreading and concurrency are nothing new, but one of the innovations of the Java language design was that it was the first mainstream programming language to incorporate a cross-platform threading model and formal memory model directly into the language specification. While this simplifies the development of platform-independent concurrent classes, it by no means makes writing concurrent classes trivial -- just easier."

Comments

So called "improved" locking

[Anonymous Coward]

One of the so called "improvements" is multiple condition variables. Except you could do multiple condition variables in java 1.x here until they "fixed" it by enforcing locking scope in the JVM rather than just in the compiler. I still have no idea what "problem" they fixed by enforcing scope except the new solution is not as clean as locks are distinct from monitors, and probably not as efficient.

JSR-166 is not a total loss as the lock-free stuff is more significant.

BTW, I came up with an improved futex based condvar for Linux (apparently I do improved condvars as a hobby) which you can find here. You can get rather dramatic performance improvements with it over NPTL condtion variables. At least until they "fix" it also.

Re:java first?

[hoggy]

Ada's multi-threading support is about two orders of magnitude better than Java's as well. It was a source of extreme disappointment to me that years of concurrency research got boiled-down to the 'synchronized' keyword.

Multi-threading is only hard because most languages have piss-poor support for multi-threading. I recommend to anyone that they go away and learn about Ada tasks and the select statement to see how it ought to be done.

Erlang

[DavidNWelton]

I have no idea about 'first' (although I kind of doubt it), but Erlang is a good language to have a look at if you're interested in concurrent programming.

So why doesn't synchronized map to ReentrantLock?

[foxed]

The article on IBM's site gives two reasons to continue using synchronized, rather than replacing it with the new ReentrantLock class:

1. You must remember to release a ReentrantLock in a finally block, while synchronized does so automatically.
2. Older JVMs don't have the concurrency classes.

Given ReentrantLock has the same semantics as synchronized, performs better and has some extra features, why hasn't synchronized been redefined to use ReentrantLock? It would become compiler magic to, in effect, automatically generate a try-finally with a call to unlock() in the finally.

The dilemma about when to use ReentrantLock would go away. For simple situations and beginning programmers, just use synchronized, confident in the knowledge that where A Better Way is available, your code will get it, but it will still work fine on earlier JVMs (assuming synchronized ever worked on them).

The extra features of ReentrantLock are there when needed, and it's only when you use them that your code is Java 5 specific.

Why wasn't it done this way?