Concurrent Hash Table Designs

weirdest part is, the initial load looks fine (try refreshing, scroll persists).

firefox's reader view helps too

turn off 1password

Looks decent on iPhone safari FWIW.

What a good transactional API is like is an interesting question.

   public void modify(K key, Function<Optional<V>,Optional<V>> modifier)

or something along those lines covers the race of a single value being changed out from under you, but if you want to update one or more keys you might want

   public void modifyMany(Set<K> key, Consumer<Map<K,V>> modifier)

where the modifier gets passed a modifiable view that has just the keys in the set.

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 ()

  atomically

  lookup :: k -> Map K v -> STM (Maybe v)

  insert :: v -> k -> Map K v -> STM ()

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.

There's a design in the .NET ConcurrentDictionary that is even more inviting:

  GetOrAdd(TKey, Func<Tkey,TValue> )

This lets you specify a key, and a method to run to generate a value to store if the key does not exist.

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.