Thread safety of std::map for read-only operations

Question

I have a std::map that I use to map values (field ID's) to a human readable string. This map is initialised once when my program starts before any other threads are started, and after that it is never modified again. Right now, I give every thread its own copy of this (rather large) map but this is obviously inefficient use of memory and it slows program startup. So I was thinking of giving each thread a pointer to the map, but that raises a thread-safety issue.

If all I'm doing is reading from the map using the following code:

std::string name;
//here N is the field id for which I want the human readable name
unsigned field_id = N; 
std::map<unsigned,std::string>::const_iterator map_it;

// fields_p is a const std::map<unsigned, std::string>* to the map concerned.
// multiple threads will share this.
map_it = fields_p->find(field_id);
if (map_it != fields_p->end())
{
    name = map_it->second;
}
else
{
    name = "";
}

Will this work or are there issues with reading a std::map from multiple threads?

Note: I'm working with visual studio 2008 currently, but I'd like this to work acros most main STL implementations.

Update: Edited code sample for const correctness.

Solution 1

This will work from multiple threads as long as your map remains the same. The map you use is immutable de facto so any find will actually do a find in a map which does not change.

Here is a relevant link: http://www.sgi.com/tech/stl/thread_safety.html

The SGI implementation of STL is thread-safe only in the sense that simultaneous accesses to distinct containers are safe, and simultaneous read accesses to to shared containers are safe. If multiple threads access a single container, and at least one thread may potentially write, then the user is responsible for ensuring mutual exclusion between the threads during the container accesses.

You fall into he "simultaneous read accesses to shared containers" category.

Note: this is true for the SGI implementation. You need to check if you use another implementation. Of the two implementations which seem widely used as an alternative, STLPort has built-in thread safety as I know. I don't know about the Apache implementation though.

Solution 2

It should be fine. You can use const references to it if you want to document/enforce read-only behaviour.

Note that correctness isn't guaranteed (in principle the map could choose to rebalance itself on a call to find), even if you do use const methods only (a really perverse implementation could declare the tree mutable). However, this seems pretty unlikely in practise.

Solution 3

Yes it is.

See related post with same question about std::set:

Is the C++ std::set thread-safe?

Comments

[foraidt]

Note: The answer is limited to the SGI STL implemenation. The OP did not mention which one is used.

[jilles de wit]

I use the implementation that comes with visual studio 2008, but I was looking for an answer that covers the std::map in general, or at least across most implementations if this is at all possible.

[laura]

Check the STL/CRL documentation(for VS20008): msdn.microsoft.com/en-us/library/bb385954.aspx. In my opinion, there is no reason why this would be untrue for the VS2008 implementation: it uses balanced binary trees as well as support for maps. I am sure they must have some sort of comment of thread safety in the documentation though

[Gunther Piez]

I would consider an implementation with mutable non thread safe internals buggy.

[jilles de wit]

I updated my code slightly to use a const reference to the map and an const_iterator

[Useless]

drhirsch, a non-threadsafe implementation could still be standards compliant, but it would certainly be poor-quality.

[Jørgen Fogh]

@Useless: Not necessarily. Splay trees update the tree during lookup, which makes it faster to look up recently accessed elements.

[Useless]

Good point, although ideally such a map wouldn't provide const accessors and then make it's tree mutable. Also: way to resurrect an old topic! :-)

[Edward Falk]

I'm not convinced. Just because nobody's modifying the map doesn't necessarily make it thread-safe. We don't know the details of the object's internals. There could be things going on under the hood such as caching that we don't know about. (I once wrote a hash table that cached the most recently-returned key-value pair)

[Edward Falk]

It seems to me that if the class is documented as not thread-safe (more specifically: not documented to be thread-safe), then it's free to implement its internals in a non-thread-safe way.

[Useless]

You're absolutely correct in general, which is why I said correctness isn't guaranteed. However, none of the standard library implementations I've looked at have mutable implementation details being mutated via const accessors/iterators. There's no reason to use them with a red-black tree. I'm certainly not aware of any std::map implemented using a splay tree.