5 ms·
Sounds like he needs a customized HashMap with a read-write lock, where most operations claim read locks, but resizing claims a write lock. That should give th
by a-priori 17y ago
Sounds like he needs a customized HashMap with a read-write lock, where most operations claim read locks, but resizing claims a write lock.
That should give the same "good enough" behaviour with similar performance (assuming resize operations are relatively rare), but will not be affected by these race conditions.
- dreish 17y agoOr a Clojure PersistentHashMap behind an Atom. That's the idiomatic way to do caching in Clojure. It would work just fine in regular Java, and you could wrap the Atom in a class that converts the usual java.util.Map methods to their equivalent Atom/PersistentHashMap operations and completely hides the fact that you're using (a non-transactional) part of the Clojure persistence framework. You don't even need Lisp! (Like any Java programmer, you will need wrist braces in a few years, though.)
- timf 17y agoIt sounds like you are describing ConcurrentHashMap (using ehcache or ConcurrentHashMap+putIfAbsent is almost always the right choice for shared access in my opinion, unless you can prove there is a bottleneck)
- timf 17y agoor something like this if you truly need a very high read rate and can stand updates not being reflected immediately: http://mina.apache.org/report/trunk/apidocs/org/apache/mina/util/CopyOnWriteMap.html http://mina.apache.org/report/trunk/apidocs/org/apache/mina/... (although I believe ehcache can do this, ehcache is so tested and widely used that I would seriously look there first)