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.)
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.
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.)
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.
Slashdot Mirror
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.)
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.
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.)
The key word was mainstream. Did anyone use ADA who didn't have to because the government told them to?
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.