Slight Disappointment in Boost’s unordered_map
Well... I won't lie to you... I'm disappointed in the boost unordered_map. I really am. In the STL std::map an iterator is not invalidated unless you're on the element in the std::map that's being deleted. That's nice. You can get an iterator on a map, and as long as your application isn't deleting elements, there's no way you're going to get into trouble. That's nice for a multi-threaded situation where there's one writer and one reader. The reader gets the iterator and the writer just shoves stuff into the map. No problems.
But that's not how the boost unordered_map works. It's not written up in any of the boost docs, but a careful search of the online message boards yields the fact that no, in fact, the iterator on the unordered_map is not valid across any write whatsoever. This is really bad news, but not totally surprising.
I've been battling a serious problem in my ticker plant, and the core dumps I was getting were in the unordered_map which made no sense to me. But now it makes perfect sense. My reader thread was expecting it's iterator to be valid for the scan, and any write was able to blow it up. It didn't happen all the time, but often enough to make it clear what was happening.
Bummer.
I read that the SGI STL hash_map was supposed to preserve iterators like the std::map, but when I tried it, I ran into the same problems as the boost unordered_map. In the end, I had to settle for simple (but fast) spinlocks on the maps as the majority of the time there will be no contention, and I don't want to slow it down that much.