Concurrent Hash Table Designs
bluuewhale.github.io
bluuewhale.github.io
public V get(Object key) { synchronized (mutex) { ... } }
public V put(K key, V value) { synchronized (mutex) { ... } }
public V remove(Object key) { synchronized (mutex) { ... } }
It is indeed trivial to reason about. This design invites users to stumble into the race condition between get and set.
public void modify(K key, Function<Optional<V>,Optional<V>> modifier)
public void modifyMany(Set<K> key, Consumer<Map<K,V>> modifier)
There is also the Clojure-style immutable API for maps though I can say I never really enjoyed working with that the way I enjoyed immutable lists (which are Lispier than Lisp: I went through all the stages of grief reading On Lisp and couldn't help think "If he was using Clojure he wouldn't be struggling with nconc)
lookup :: k -> Map K v -> STM (Maybe v)
insert :: v -> k -> Map K v -> STM ()
https://hackage-content.haskell.org/package/stm-containers/d...
GetOrAdd(TKey, Func<Tkey,TValue> )
This is thread-safe, however it is not atomic much to the surprise of many that use it.
If you wrongly assume that the factory method can only execute once, you fall into a trap, since it actually can execute many times before the result is stored.
This can cause a problem if you use it for caching, because you might for example put an expensive calculation you want to cache there, only to find out cache expiration causes a stampede as the factory suddenly executes a lot at once.
firefox's reader view helps too
really