views:

332

answers:

2

I'm looking for a associative container of some sort that provides safe concurrent read & write access provided you're never simultaneously reading and writing the same element.

Basically I have this setup:

Thread 1: Create A, Write A to container, Send A over the network.

Thread 2: Receive response to A, Read A from container, do some processing.

I can guarantee that we only ever write A once, though we may receive multiple responses for A which will be processed serially. This also guarantees that we never read and write A at the same time, since we can only receive a response to A after sending it.

So basically I'm looking for a container where writing to an element doesn't mess with any other elements. For example, std::map (or any other tree-based implementation) does not satisfy this condition because its underlying implementation is a red-black tree, so any given write may rebalance the tree and blow up any concurrent read operations.

I think that std::hash_map or boost::unordered_set may work for this, just based on my assumption that a normal hash table implementation would satisfy my criteria, but I'm not positive and I can't find any documentation that would tell me. Has anybody else tried using these similarly?

A: 

Common hash table implementation have rehashing when the number of stored element increase, so that's probably not an option excepted if you know that this doesn't happen.

I'd look at structures used for functional languages (for instance look at http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf) but note that those I'm currently thinking about depend on garbage collection.

AProgrammer
I definitely didn't think about the resize issue, whoops. It seems to me though that there should be a solution that doesn't involve a full copy on a resize. It would probably involve keeping around a set of hash tables, which you add to when you run out of space. Not exactly sure what performance implications this would have, but I feel like I've seen something to this effect elsewhere before.
Paul D.
+1  A: 

The STL won't provide any solid guarantees about threads, since the C++ standard doesn't mention threads at all. I don't know about boost, but I'd be surprised if its containers made any concurrency guarantees.

What about concurrent_hash_map from TBB? I found this in this related SO question.

Philip Potter
Sweet, I will take a look at that. I'd much rather find a free implementation (I'm looking to use this at work), but that is the only concurrent container implementation I've seen inside a legitimate library (as opposed to code off some random guys blog).
Paul D.
It's GPL. Isn't that free enough?
Philip Potter
Whoops. Yeah, after reading over the website it looks like it's free even for commercial use unless you want their support package. Also it's not lock-free, it uses fine grained locking, but it looks like it performs really well, I'm definitely going to do some benchmarking against what I'm using now (std::map with course grained locking).
Paul D.