
A Beautiful Race Condition - beza1e1
http://mailinator.blogspot.com/2009/06/beautiful-race-condition.html
======
a-priori
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.

~~~
timf
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
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/...](http://mina.apache.org/report/trunk/apidocs/org/apache/mina/util/CopyOnWriteMap.html)

(although I believe ehcache can do this, ehcache is so tested and widely used
that I would seriously look there first)

------
tptacek
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-
vulnerabil...](http://www.matasano.com/log/201/today-on-this-old-
vulnerability/)

------
rs
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!

