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."
Is this "Slashdot Java Day"? I completely forgot to buy Taco a card!
What I'm listening to now on Pandora...
The util.concurrent package has been very popular among open-source projects, and is known for its strong performance. In many cases, migrating from util.concurrent should be as simple as importing java.util.concurrent.class instead of EDU.oswego.cs.dl.util.concurrent.class .
Of course, one of the improvements made by JSR166 is to genericize all the interfaces and classes, so what uses to be a BlockingQueue is now a type-safe, parameterizable class BlockingQueue<E>.
Not all of the toolkit made it into the 5.0 release in time, and the missing stuff, referred to as jsr166x, which comprises "concurrent sorted maps and sets, as well as concurrent double-ended queues (deques)", is available for use.
Doug also offers a JSR166 maintenance update that fixed a bug in one of the classes.
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.
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.
http://www.welton.it/davidw/
- You must remember to release a ReentrantLock in a finally block, while synchronized does so automatically.
- 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?