First class developer: who ?
in [Java Help]
|
Prev: Speaking of thread safety?
Next: solutions manual to A First Course In Probability 7th Edition by Sheldon M. Ross
From: Mike Schilling on 21 Mar 2010 01:53 Arved Sandstrom wrote: > Arved Sandstrom wrote: > [ SNIP ] > >> After all, given no requirements other than correctness, I don't >> have to produce a ConcurrentLinkedQueue that is as performant or >> efficient or elegant, with extra classes like >> java.util.concurrent.atomic.AtomicReferenceFieldUpdater and >> sun.misc.Unsafe, as what Doug Lea wrote. > > I meant to add, there isn't a single use of the "synchronized" keyword > in ConcurrentLinkedQueue. I consider myself a competent concurrency > programmer, but not a god like Doug Lea or Brian Goetz. My estimate > was based on being allowed to use "synchronized", which as a first > cut is a sensible thing to do. No, that's cheating :-) The whole point of ConcurrentLinkedQueue is to achieve concurrency without locking the queue down. And you know what? It's complicated.
From: Arved Sandstrom on 21 Mar 2010 09:19
Mike Schilling wrote: > Arved Sandstrom wrote: >> Arved Sandstrom wrote: >> [ SNIP ] >> >>> After all, given no requirements other than correctness, I don't >>> have to produce a ConcurrentLinkedQueue that is as performant or >>> efficient or elegant, with extra classes like >>> java.util.concurrent.atomic.AtomicReferenceFieldUpdater and >>> sun.misc.Unsafe, as what Doug Lea wrote. >> I meant to add, there isn't a single use of the "synchronized" keyword >> in ConcurrentLinkedQueue. I consider myself a competent concurrency >> programmer, but not a god like Doug Lea or Brian Goetz. My estimate >> was based on being allowed to use "synchronized", which as a first >> cut is a sensible thing to do. > > No, that's cheating :-) The whole point of ConcurrentLinkedQueue is to > achieve concurrency without locking the queue down. And you know what? > It's complicated. I don't consider this cheating at all. Your language was, "If you had to implement something like a ConcurrentLinkedQueue from scratch". You'll note the "something like a". How "like"? If I'm permitted to go off the published API (e.g. http://java.sun.com/javase/6/docs/api/java/util/concurrent/ConcurrentLinkedQueue.html) , which certainly meets your stated requirements (in fact it's even more strict than what you asked for), then using synchronized methods is perfectly adequate. From a software engineering standpoint I'd be silly to produce a Lamborghini when you only asked for a Honda. If you wish to impose additional requirements, namely on the implementation, feel free. I'll point out, though, that there's still a lot of room between a straight synchronize-all-methods approach (OK, it's not quite that simple, but it's close) and the Ultimate Engineering that we see in the actual JDK class. My argument is that substantial improvements, over and above the simplest synchronize-all-methods approach, can be achieved with approaches considerably less refined and intricate than the Lea implementation. You can guess that the simplest approach, one based on synchronizing the top-level methods, doesn't take long at all. Just for giggles I wrote a new ConcurrentLinkedQueue from scratch yesterday, complete with about 25 JUnit tests so far, and one load test that runs through a reasonably complicated queue operations sequence for many threads, and it's doing just fine. No doubt in my mind that you and many other people would have knocked out the same thing in about the same amount of time. I'll probably try some improvements in the direction that you suggest, just for fun. As to whether an improved implementation would require more time or about the same amount of time as TreeMap, that depends entirely on what the performance requirements are. I think a good concurrency programmer could implement adequate next-stage mechanisms and not spend appreciably more time on this class than they would on TreeMap. You should remember, the core logic of ConcurrentLinkedQueue is not exactly all that complicated. AHS |