Slashdot Mirror
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."
dont know about first mainstream, but when it comes to a cross-platform threading model, i think ADA was first
Is this "Slashdot Java Day"? I completely forgot to buy Taco a card!
What I'm listening to now on Pandora...
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.
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.
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*
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
And has a few trollish statements against Democrates. It is fine to defend your stance as a Bush voter, it is your right, but please, listen to the following:
Those who voted Bush gave thier first and only affirmative acceptance and vote of persnal merit to the actions undertaken in Iraq. Prior to this no American had given a personal vote of acceptance to the actions undertaken, if you voted Bush, then you approve of Fallujah, of the troops for oil programs, and the rest.
You voted into power the wealthiest cabinet in the history of all nations. Thier personal assets are shocking.
That is all, sorry, please mod OT, or even insightful for this thread! and don't feed the trolls.
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
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.
From the story submission: Have fun in C++ land though!
The fact you think the only possible alternative I could mean is C++ discredits you.
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
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/
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 there are several good cross platform thread abstraction libraries (see ACE, for example). 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.
FreeSpeech.org
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.
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
while (!asleep()) sheep++
- 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?
What they should have done was make MonitorEnter and MonitorExit methods of java.lang.Object and have the compiler generate calls to them when encountering a synchronized block. Then all you'd have to do to use different locks would be to override those two methods. Likewise for notify and wait. There would be some complications but essentially, that's it.
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.
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.
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
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
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
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
Actually, you are Wrong!
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.
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.
Nope, the bill said "if Saddam Hussein refuses to give up weapons of mass destruction". The inspections were done to the point where the UN along with other countries said he had them. He had to GIVE THEM UP.
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 had kicked the inspectors out, and wouldn't give them access to where they wanted to go so he was in violation of the UN resolution so the Bill gave Bush permission to attack.
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.
Try reading the fucking thing, he was in violation of the UN resolution for impeding and kicking the inspectors out at one point.
Do you have any other way you can twist this to fit your backward logic and failed ideology?
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 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.
while (!asleep()) sheep++
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?
Everything will be taken away from you.
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?
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com