mrkeen
a month ago
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.
PaulHoule
a month ago
What a good transactional API is like is an interesting question.
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)
mrkeen
a month ago
STM containers does it right.
lookup :: k -> Map K v -> STM (Maybe v)
insert :: v -> k -> Map K v -> STM ()
https://hackage-content.haskell.org/package/stm-containers/d...
user
a month ago
eterm
a month ago
There's a design in the .NET ConcurrentDictionary that is even more inviting:
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.
the-smug-one
a month ago
I don't see the problem at all, tbh. Both `get(K); put(K);` and `put(K); get(K);` are valid execution traces on a uniprocessor.
mrkeen
a month ago
Oh yeah, I'm not sure what an execution trace is, but ConcurrentHashMap is indeed fit-for-purpose for single-threaded use.