An amazing lecture, exactly what I needed, but I feel obligated to point out one possibly confusing thing: 1:48 The way you explain hash function suggest it's random while it has nothing to do with randomness (neither true nor pseudo) since hash function for a given key must always return the same result- it's perfectly deterministic.
Karol, you are correct - hash functions are definitely not random, or they wouldn't work at all! I probably should have said "pseudo-random", so thanks for clarifying this!
Thanks Prof Doug for updating your course with ConcurrentHashMap implementation details. I think this is something newly added. I had the impression that changes in ConcurrentHashMap are visible to all the readers. In the get() API, if the key is not found, then a lock is eventually taken and so the readers will see the newly added key.Also as you said, the value field is volatile so, readers will see the changes in values immediately. I think, the iterators created before the update might miss the newly added keys, but if we create iterators after update, they will see all the changes made. Please let me know if I am missing something.
Please see the overview section of docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html that describes the semantics of iterators in the context of ConcurrentHashMap.
Segments still exist in the Java 8+ code, though only for backwards compatibility wrt serialization, as per this comment in the code: 'We also declare an unused "Segment" class that is instantiated in minimal form only when serializing.' The key point, however, is that there are different locks for each hash bin, hence less contention than a SynchronizedLock!
![ตีสิบเดย์ [FULL] | คู่รักแซฟฟิก "หลิงหลิง - ออม" จากซีรีย์ "ใจซ่อนรัก"](http://i.ytimg.com/vi/zs8AfphGn2w/mqdefault.jpg)
really good
An amazing lecture, exactly what I needed, but I feel obligated to point out one possibly confusing thing: 1:48
The way you explain hash function suggest it's random while it has nothing to do with randomness (neither true nor pseudo) since hash function for a given key must always return the same result- it's perfectly deterministic.
Karol, you are correct - hash functions are definitely not random, or they wouldn't work at all! I probably should have said "pseudo-random", so thanks for clarifying this!
Wonderful lesson!
Glad you liked it Gerson!
Thanks Prof Doug for updating your course with ConcurrentHashMap implementation details. I think this is something newly added.
I had the impression that changes in ConcurrentHashMap are visible to all the readers.
In the get() API, if the key is not found, then a lock is eventually taken and so the readers will see the newly added key.Also as you said, the value field is volatile so, readers will see the changes in values immediately.
I think, the iterators created before the update might miss the newly added keys, but if we create iterators after update, they will see all the changes made.
Please let me know if I am missing something.
Please see the overview section of docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html that describes the semantics of iterators in the context of ConcurrentHashMap.
best lecture
Hi, In Java 8 CHM implementation has got changed. It does not use segments anymore. Could you please recheck.
Segments still exist in the Java 8+ code, though only for backwards compatibility wrt serialization, as per this comment in the code: 'We also declare an
unused "Segment" class that is instantiated in minimal form only when serializing.' The key point, however, is that there are different locks for each hash bin, hence less contention than a SynchronizedLock!