Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Java Programming

JDK 5.0: More Flexible, Scalable Locking 50

Posted by Hemos from the looking-forward-to-the-path dept.
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."
This discussion has been archived. No new comments can be posted.

JDK 5.0: More Flexible, Scalable Locking More

JDK 5.0: More Flexible, Scalable Locking

Comments Filter:

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

    • Re:java first? (Score:3, Insightful)

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

      • Re:java first? (Score:5, Interesting)

        by hoggy ( 10971 ) * on Monday November 22, 2004 @11:26AM (#10888712) Homepage Journal
        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 (Score:4, Interesting)

      by DavidNWelton ( 142216 ) on Monday November 22, 2004 @12:47PM (#10889598) Homepage
      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.
      • 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.
    • The key word was mainstream. Did anyone use ADA who didn't have to because the government told them to?
    • 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!
      • ...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? (Score:4, Funny)

    by Otter ( 3800 ) on Monday November 22, 2004 @10:09AM (#10888040) Journal
    Is this "Slashdot Java Day"? I completely forgot to buy Taco a card!

  • So called "improved" locking (Score:2, Interesting)

    by Anonymous Coward
    One of the so called "improvements" is multiple condition variables. Except you could do multiple condition variables in java 1.x here [google.com] 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 fut

  • Doug Lea's concurrent Java (Score:5, Informative)

    by Earlybird ( 56426 ) <{slashdot} {at} {purefiction.net}> on Monday November 22, 2004 @10:46AM (#10888343) Homepage
    JSR166 [jcp.org], the specification implemented in JDK 5.0, is essentially an improved, cleaned-up version of Doug Lea's [oswego.edu] 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 [oswego.edu], 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 [oswego.edu] that fixed a bug in one of the classes.

    • 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
    • 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.)
  • 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.

    We've had threading in libraries for years (e.g. DCE, Posix, and NT threads). In fact, doesn't Java itself use those libraries to provide its own cross platform thread abstraction? In that sense, Java is nothing special in that ther
    • 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"...
    • 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 t
      • 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 an

        • 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

  • So why doesn't synchronized map to ReentrantLock? (Score:3, Interesting)

    by foxed ( 152267 ) on Monday November 22, 2004 @06:18PM (#10892956)
    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?


    • 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" t
      • 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

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

  • 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 possibilit
    • 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

Slashdot Top Deals

Think of it! With VLSI we can pack 100 ENIACs in 1 sq. cm.!

Close