12/30/2025 at 7:02:27 PM
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.
by mrkeen
12/30/2025 at 10:02:50 PM
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)
by PaulHoule
12/30/2025 at 10:03:47 PM
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.
by eterm
12/31/2025 at 11:36:43 AM
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.by the-smug-one