4 ms·

Such a strong wording lead me to check this library doc but I couldn't find anything in there unexpected or that looked particularly original, but only classica

by rixed 7y ago

Such a strong wording lead me to check this library doc but I couldn't find anything in there unexpected or that looked particularly original, but only classical message queues, semaphores, futures and locks. Could it be that I looked at the wrong thing? Could you be more specific about what triggered such an enthusiastic description?

bsder 7y ago
Reference here: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/package-summary.html https://docs.oracle.com/javase/8/docs/api/java/util/concurre... Take a good look at things like ConcurrentLinkedDeque or ConcurrentSkipListSet and then look at what guarantees they do and do not make and think about the rationale behind those decisions. And all you have to do in java is create the collection, hand the reference to multiple threads, and IT JUST WORKS like a normal Java collection. You do NOT want to be using semaphores and locks directly if you have java.util.concurrent at your disposal. Look at the "Concurrent Collections" section: Most concurrent Collection implementations (including most Queues) also differ from the usual java.util conventions in that their Iterators and Spliterators provide weakly consistent rather than fast-fail traversal: they may proceed concurrently with other operations they will never throw ConcurrentModificationException they are guaranteed to traverse elements as they existed upon construction exactly once, and may (but are not guaranteed to) reflect any modifications subsequent to construction. These are remarkably difficult properties to get correct. Then you have to think about fairness vs progress (the java.util.concurrent folks have thought about this a LOT). That library is something I sorely miss when I'm operating in another language. You should also dive into the code itself. Sometimes you'll look at a function and marvel at how much work it really takes to get something right. And sometimes you'll look at a function and wonder how it could possibly be so simple.
- rixed 7y ago
  I will have to look at the implementation some day, but I think I am starting to see what you mean with the API. Is the typical implementation of those days structures relying on many small scale mutexes to avoid contention, or RCU techniques ?
  - bsder 7y ago
    Mostly compare-and-swap mechanisms at critical points so that everything is always consistent (for very specific definitions of consistent). I think there are alternative paths when contention starts becoming too high. It's been a while, but the code is the real reference. You can go back and look at the mailing list archives as well. http://cs.oswego.edu/mailman/listinfo/concurrency-interest http://cs.oswego.edu/mailman/listinfo/concurrency-interest

by rixed 7y ago

bsder 7y ago

Reference here: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/package-summary.html https://docs.oracle.com/javase/8/docs/api/java/util/concurre... Take a good look at things like ConcurrentLinkedDeque or ConcurrentSkipListSet and then look at what guarantees they do and do not make and think about the rationale behind those decisions. And all you have to do in java is create the collection, hand the reference to multiple threads, and IT JUST WORKS like a normal Java collection. You do NOT want to be using semaphores and locks directly if you have java.util.concurrent at your disposal. Look at the "Concurrent Collections" section: Most concurrent Collection implementations (including most Queues) also differ from the usual java.util conventions in that their Iterators and Spliterators provide weakly consistent rather than fast-fail traversal: they may proceed concurrently with other operations they will never throw ConcurrentModificationException they are guaranteed to traverse elements as they existed upon construction exactly once, and may (but are not guaranteed to) reflect any modifications subsequent to construction. These are remarkably difficult properties to get correct. Then you have to think about fairness vs progress (the java.util.concurrent folks have thought about this a LOT). That library is something I sorely miss when I'm operating in another language. You should also dive into the code itself. Sometimes you'll look at a function and marvel at how much work it really takes to get something right. And sometimes you'll look at a function and wonder how it could possibly be so simple.

rixed 7y ago
I will have to look at the implementation some day, but I think I am starting to see what you mean with the API. Is the typical implementation of those days structures relying on many small scale mutexes to avoid contention, or RCU techniques ?
- bsder 7y ago
  Mostly compare-and-swap mechanisms at critical points so that everything is always consistent (for very specific definitions of consistent). I think there are alternative paths when contention starts becoming too high. It's been a while, but the code is the real reference. You can go back and look at the mailing list archives as well. http://cs.oswego.edu/mailman/listinfo/concurrency-interest http://cs.oswego.edu/mailman/listinfo/concurrency-interest