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

java first?

[BigBadDude]

dont know about first mainstream, but when it comes to a cross-platform threading model, i think ADA was first

Re:java first?

[ClosedSource]

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

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:java first?

[BrianGoetz]

The key word was mainstream. Did anyone use ADA who didn't have to because the government told them to?

Re:java first?

[bmckinle]

Hardly, Ada was mainstream in the 80's and even in commercial circles at the time. Didn't Modula have one, though it was not really mainstream. Java Developers' lifecycles are too short it seems to appreciate standing on the shoulders of language giants that preceeded them. Where do you think Java Threading got some of its best ideas from? What do you think Java's lifecycle will be?

Enjoy!

Re:java first?

[bmckinle]

...and something I've thought interesting since Java's inception is that Thread.stop() is not realiably implementable, semantically, in any language. Ada language developers knew this and accounted for this in the language initially but the Java folks failed to pick it up until well after 1.0--deprecated now. Just goes to show you that understanding concurrent programming models is much more useful than concurrent programming languages in the long run.

Enjoy!

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.

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:Doug Lea's concurrent Java

[BrianGoetz]

You're missing some significant improvements in the implementation, which have been completely rewritten, to take advantage of improvements in the Java Memory Model and the exposure of CAS-like primitives in the JVM for 5.0. As a result, most of the classes in j.u.c use wait-free, lock-free algorithms instead of lock-based ones, offering better performance and scalability than u.c. There's a lot more there than simply a cleaned-up, generified u.c (although its u.c heritage shows through clearly.)

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*

Pthreads does *not* include a formal memory model

[jdennett]

So POSIX threads don't predate Java in this respect.

And pthreads aren't quite pervasive enough to count as "might as well be part of the language" -- I've worked on many C implementations that did not have pthreads capabilities, even though a good fraction of them did have some kind of threading.

Before telling people they're ignorant, it's good to be sure of your own information.

For example, I'm tempted to say that the POSIX committee is being disbanded, but I don't have official confirmation of that so I'll just mention it as a possibility at this time.

Re:Bah

[Jerf]

Who cares about anything in your last paragraph?

From the story submission:

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

Have fun in C++ land though!

The fact you think the only possible alternative I could mean is C++ discredits you.

can I use it with classPath ?

[johnjones]

methink's no

so frankly whats the point

I want an open JVM and that means open Libs if I am going to bugfix and then take my ball and play elsewhere

yes there is parrot but think a good set of libs like the CLR for parrot would be good...

but I want to use java maybe now...

regards

John Jones

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.

Re:Erlang

[renoX]

Bzzzzt, you did a 'selective quote', he said 'first mainstream' language.

I don't consider Erlang a mainstream language: its userbase is quite small..

Does Ada qualify as mainstream?

IMHO yes, but YMMV.

Re:Bah

[Nevyn]

POSIX threads; not only cross-platform and essentially built into C

You mean apart from win32, right? ... that's only what, a couple of hundred million hosts.

Maybe python lets you do useful cross platform threading ... but I didn't think so, and I'm not sure I'd classify it mainstream anyway (certainly not to the extent that Java is -- and personaly I think python is a better lanugage, but it isn't as mainstream).

Then again I think the entire argument is bogus, it's like advocating for GCC because that's the first compiler that allowed you to have computed goto's. Threads are not the answer, they are the question and the answer is no.

Re:Parent voted for Bush

[ClosedSource]

Actually, Congress didn't vote to go to war in Iraq, they merely gave the president the option in order to pressure Iraq to allow the weapon inspectors to finish their work (the fact the Congress starting in the 2nd half of the 20th century has given away their sole constitutional authority to initiate a war is a subject for another day).

Bush himself said before the vote that it wasn't a vote to go to war. Of course he's proven on many occasions that lying is not a problem for him.

.. 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?

Re:Parent voted for Bush

[DAldredge]

You know, you didn't address any of the points I brought up.

Not one.

Article Failings and Synchronized vs Locks

[ban]

I have a few issues with this article. Why isn't there any mention of exactly which JVM he is using? Why is there no source code for his tests?

I happen to write a JVM for a living, and there are huge differences between how locks perform in different situations on the different VMs.

When it comes to using synchronized vs Locks, and that synchronized should be implemented with the methods in Lock et.c. people tend to miss two important facts.

1. Having monitorEnter/monitorExit paired gives you nice possibilities for optimization (like keeping track of recursion depth as a result of the lock operation, since you know which unlock should be the real unlock et.c.).
2. You can potentially synchronize on every object in Java, and uncontended thread local synchronization should be fast and not introduce memory overhead.

If you think that the implementation of synchronized use O/S or user level mutexes as the implementation for the fast case you should probably read http://citeseer.ist.psu.edu/bacon98thin.html and continue with the articles referencing it.

But then again, this is Slashdot, why would people read anything about the subjects they're commenting on.

Re:Article Failings and Synchronized vs Locks

[BrianGoetz]

The tests used the Sun JDK 5.0 on Windows and Linux. I thought that was entirely clear from the headings, but perhaps not.

Why no source code? Well, I have no objection to posting it, but I thought it would detract from the point. This is an article for beginners, who want to know when and how to use these new language features and what it buys them.

You are correct that the actual numbers are going to be sensitive to the distribution of other work done in the inner loop other than locking. The goal of including the graphs was not to exactly quantify the scalability improvement of RL over synchronized (an absurd goal for an article of this type), which requires covering a many-dimensional search space, but instead to offer a qualitative snapshot drawn from a believeable example.

Actually, what processor you use makes a huge difference, perhaps more than the JVM. For example, CAS performance on Intel processors varies tremendously across hardware revisions, and in turn is pretty different from CAS performance on Sparc and other architectures.

Re:So why doesn't synchronized map to ReentrantLoc

[angel'o'sphere]

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.

Because that compiler magic would move towards real magic in case you have programmer defined try/finally blocks allready.

Suppose you have a exception comming from way down under library calls ... now you have to "try" to realeasy semaphores and get a new exception. Hopefully you have saved the previous exception somewhere ... because now you fix your semaphore in the compiler crafted finally block. And in the end of your finally block you have to throw the saved exception, which came from way down ... I think that is not easy solveable.

Hm, I'm not sure if it is even legal to throw an exception from a finally block, but should be, shouldned it, no?

angel'o'sphere

Re:Bah

[angel'o'sphere]

POSIX threads; not only cross-platform and essentially built into C


Thats a C library. And not a language feature.

HUGHE difference. The compiler dosn't know anything about pthreads ....

angel'o'sphere

Re:Bah

[JavaLord]

If you ever think Java did something first, odds are, it's your ignorance showing.

What does first matter? Java does everything THE BEST so being first really means nothing. ;)

Re:So why doesn't synchronized map to ReentrantLoc

[BrianGoetz]

The short answer is that since the 5.0 JVM and java.util.concurrent.lock were developed, well, concurrently, it would not have been practical (even if they wanted to) to make synchronized work in terms of ReentrantLock for JDK 5.0.

There are more complicated reasons, but I think its safe to say that there are a lot of people at Sun who have already thought of this, and that there will be scalability improvements in synchronization in future JVM versions.

Re:Laguage or Library

[BrianGoetz]

Duh, could you miss the point any more? No one claims Java invented threading. The key is the formal, cross-platform memory model.

Different processors have different memory semantics (differing degrees of cache coherency, for example), and most threading libraries simply "inherit" the memory semantics of the underlying processor architecture, so concurrent code may well behave differently on one processor that it will on another. This is why a formal, cross-platform memory model is required to achieve true portability across platforms for concurrent code. (Posix provided a hint of that, but the others were entirely silent on the subject.)

Re:Dumbass doesn't know what he is talking about

[ClosedSource]

According to the story at your link:

"In a major victory for the White House, the Senate early Friday voted 77-23 to authorize President Bush to attack Iraq if Saddam Hussein refuses to give up weapons of mass destruction as required by U.N. resolutions."

The CNN story doesn't provide the actual text of the bill and I'm too lazy to look it up.

It seems to me that in order to determine if there were weapons of mass destruction, you'd have to finish the inspections and that would be an implicit (if not explicit) part of the bill.

But let's say I'm totally wrong as you state. Saddam Hussein could have kicked the inspectors out of the Iraq without fear of President Bush invading because the bill only authorizes him to invade if Saddam posesses WMDs. Saddam didn't have any WMDs but Bush invaded Iraq anyway. So the invasion had nothing to do with the Congressional action since the triggering conditions never occured.

Re:Parent voted for Bush

[ClosedSource]

If you say so.

Re:Laguage or Library

[Skjellifetti]

Different processors have different memory semantics (differing degrees of cache coherency, for example), and most threading libraries simply "inherit" the memory semantics of the underlying processor architecture, so concurrent code may well behave differently on one processor that it will on another.

This sounds like a lot of nonsence to me. C libs like pthreads run on top of an OS which runs on top of the processor. In what way are differences in cache coherency among processors exposed by the OS and thread libs such that concurrent code behaves differently from one processor to another -- or at least differently enough that I would ever care enough to rewrite thread code written for, say, ix86/Linux vs. sparc/Solaris? Remember, too, that Java runs on top of libs such as pthreads. How exactly is Java different from any other app that uses portable C code and links against standard posix C libs? And don't tell me its the memory model. Why can't I just use one of the many replacement thread-safe mallocs to achieve the same thing?

I like Java. It is quite a useful language and the many libraries, APIs and frameworks built around it make it easy to create powerful programs. But its cross platform features have been available for many years to C coders using various cross platform libraries that solve the same cross platform problems that Java solves.

Re:Jesus Christ man, take off the blinders

[ClosedSource]

Nope, the bill said "if Saddam Hussein refuses to give up weapons of mass destruction".

And he didn't have any WMDs.

"Do you have any other way you can twist this to fit your backward logic and failed ideology?"

I didn't express any ideology failed or otherwise. As far as backward logic is concerned, it's you who insists that Bush met the terms of the bill since Saddam wouldn't give up the imaginary WMDs.

I'll let you have the last word.

Re:So why doesn't synchronized map to ReentrantLoc

[foxed]

I see the problem.

But synchronized has the same issue - there may be times that releasing the lock doesn't work and throws an exception. The JVM spec says the underlying monitorexit bytecode instruction can throw NullPointerException or IllegalMonitorStateException. Both of these are runtime exceptions that would most likely stop the whole application, and would certainly hide any exception that had occurred in the code within the block. As you might expect, the unlock() method of ReentrantLock can throw exactly the same exceptions.

I don't see why the exception is any more likely to occur if synchronized was implemented with ReentrantLock.

A developer choosing to directly use ReentrantLock in a stupid way might get exceptions, but that is the point of synchronized in the first place - simplify, automate and abstract to make it easier for the developer to write correct code.

It's the memory model..

[fforw]

How exactly is Java different from any other app that uses portable C code and links against standard posix C libs? And don't tell me its the memory model. Why can't I just use one of the many replacement thread-safe mallocs to achieve the same thing?

It's the memory model.. =)

It defines how information can be cached for a thread, when this information has to be written back into main memory, which kind of operations are atomic. etc.

It's not just about memory allocation and disposal but access to that memory whith different threads/cpus.

Re:Bah

[Joe Tie.]

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.

Wait....qt? Did you just miswrite that, or did an swt implementation with qt support, official or unofficial, finally make it out somewhere in the wild?

Re:Bah

[tod_miller]

if it doesnt exist then it is a mistake on my part, I know there are two viable toolkits for swt on linux, which two?

Aaaah motif and gtk. Why not a qt impl? Code so drastically different?