The Vec<RwLock<HashMap>> seems like a great hack, though you might still benefit from trying to come up with a scheme that avoids that RwLock (which internally uses a Mutex - as far as I know, even on reads), which can be slow if you have a lot of reads. (That's why evmap [and most lock-free structures I've ever heard of] use epochs [which is kind of like double buffering writes to batch up updates].)
The problem is that I'm actually using the HashMap not only for concurrency but also for synchronization. Looking at the Java ConcurrentHashMap it wouldn't work. I need the equivalent of an RwLock per key so that stale data is never read and there are never two writers for the same key. But thinking about it, it's a fairly different data structure from ConcurrentHashMap.
