Ed's latest article: A Java Reactive Generator http://coopsoft.com/ar/ReactiveArticle.html
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
"I'm not back." - Bill Harding, Twister
Originally posted by Jim Yingst:
Sometimes those are exactly what you want. However I think often you need synchronization at a higher level than that. If you have two or more fields and you need them to have a consistent relationship - e.g. if you're transferring a balance from one account to another - then you probably need to make sure that no other threads modify those values in the middle of the transfer. I don't see how you can do that with atomic primitives. Am I missing something?
Ed's latest article: A Java Reactive Generator http://coopsoft.com/ar/ReactiveArticle.html
"I'm not back." - Bill Harding, Twister
Originally posted by Jim Yingst:
So, java.util.concurrent.locks does use atomic methods, but not "the atomic classes". Implementation aside, I think it's a mistake to say "don't use locks, use atomic primitives" because that seems to rule out the very useful Lock classes. However I think we might all agree on something like "avoid synchronization, prefer java.util.concurrent locks or atomic primitives instead". Sound good?
"I'm not back." - Bill Harding, Twister
Ed's latest article: A Java Reactive Generator http://coopsoft.com/ar/ReactiveArticle.html
Originally posted by Edward Harned:
The discussion is about deadlocks but there are four problems with using locks in any form:
1. Deadlock,
2. Starvation,
3. Priority Inversion,
4. Excessive Overhead.
Starvation happens when the thread holding the lock refuses to give it up (knowingly or otherwise), the waiting threads starve.
Priority Inversion occurs when a lower priority thread is ahead of a higher priority thread in the queue of waiting threads. Since the lower priority thread gets the lock before the higher priority thread, it�s an inversion.
Now using Lock() instead of synchronize helps with the above problems, but nothing helps with the overhead problem.
The longer the queue of waiting threads the more overhead. Until you watch this in action you�ll have a hard time believing it is really a problem. Sure, the dispatcher has to check the waiting threads to see if any thread is ready to run, so what? It�s what has to be checked and how long it takes that makes long queues a real problem.
If you work with multi-threading in a large SMP server environment, atomic is the way to go. It does take a different mind set but it�s only a learning curve.
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |