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

WTF?

[Otter]

Is this "Slashdot Java Day"? I completely forgot to buy Taco a card!

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?

[ClosedSource]

I don't know if Ada was the first, but it certainly had cross-platform threading before Java was created.

Doug Lea's concurrent Java

[Earlybird]

JSR166, the specification implemented in JDK 5.0, is essentially an improved, cleaned-up version of Doug Lea's public-domain util.concurrent package, a set of pattern-based building blocks for concurrent programming that have been very popular; Doug Lea himself is the specification lead on JSR166.

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.

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.

Re:Bah

[tod_miller]

What? Who cares about anything in your last paragraph? Java is Java if it was first, second, third or last.

Hasn't done one original thing? Well, a cross platform skinnable lightweight UI package that sits on top of a JIT bytecode compiler, that gives you binary compatibility between MFC, GTK, qt and other libraries.... that is pretty cool.

Alsom the JCP is pretty revolutionary in software development, and a very good start for originality.

Linux community never really adopted Java, it is a shame, it isn't a system programming language in terms of writing OS's (although there is an OS, blah blah) it is an application language.

Java needs more open source approval, there are awesome java based applications on freshmeat, and more added all the time.

Java is an excellent application development platform. If it is not for you then say so and move on! :-)

Your statement: Java is great... I guess, personally I think it's the worst thing to happen to systems programming since C++ makes me discredit most of what you say, sorry.

Have fun in C++ land though! I envy you!! NO I DO!! *stiffles painful laugh and then remembers C++ days and goes into shock*

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.

.. and formal memory model

[fforw]

Or to quote the Bell Labs proverb: "library design is language design" so Java is hardly the first language to incorporate a cross-platform threading model.

[...] to incorporate a cross-platform threading model and formal memory model directly into the language specification. [...] I think the keyword in this case is the "and"...

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?