3 ms·

A Beautiful Race Condition

25 points by beza1e1 17y ago

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 ago
  Or 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 ago
  It 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 ago
    or 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)
tptacek 17y ago
I have a favorite race condition, too. I think it's simpler to describe than Tyma's, and it has a cooler effect. http://www.matasano.com/log/201/today-on-this-old-vulnerability/ http://www.matasano.com/log/201/today-on-this-old-vulnerabil...
rs 17y ago
IIRC the javadoc for HashMap does warn you about this I hit this issue in production about 2/3 years back and it didn't affect the functionality of the running process that much, but there was a thread spinning endlessly for a few days until the next restart window. Moral of the story: remember to use the right tool for the job and read the usage manual!

25 points by beza1e1 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 ago
Or 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 ago
It 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 ago
  or 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)

tptacek 17y ago

I have a favorite race condition, too. I think it's simpler to describe than Tyma's, and it has a cooler effect. http://www.matasano.com/log/201/today-on-this-old-vulnerability/ http://www.matasano.com/log/201/today-on-this-old-vulnerabil...

rs 17y ago

IIRC the javadoc for HashMap does warn you about this I hit this issue in production about 2/3 years back and it didn't affect the functionality of the running process that much, but there was a thread spinning endlessly for a few days until the next restart window. Moral of the story: remember to use the right tool for the job and read the usage manual!