Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Reference here: 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.



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 ?


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: