Subtle MT problem with __gnu_cxx::hash_map

[Matt Austern]

On Nov 19, 2004, at 12:38 PM, Lothar Werzinger wrote:

> On Friday 19 November 2004 12:30, Matt Austern wrote:
>> On Nov 19, 2004, at 12:21 PM, Paul Dubuc wrote:
>>> There's a subtle thread safety problem with hash_map that was found 
>>> in
>>> our testing recently.  It's understood that operator[] is a non-const
>>> method since it can insert an element into a container if one is not
>>> found with the given index.
>>>
>>> In our case we were using operator[] to access a hash_map that had
>>> been fully populated.  Each index we were using did have an entry in
>>> the hash_map.  So we were accessing elements in the map with
>>> operator[] using multiple threads thinking that this would be a 
>>> thread
>>> safe, const operation.  This is implied by the statement 
>>> "simultaneous
>>> read accesses to to shared containers are safe" in the SGI STL user's
>>> guide (http://www.sgi.com/tech/stl/thread_safety.html).
>>
>> But operator[] isn't read access.  It's defined to be equivalent to a
>> certain form of insert().
>
> If one can be sure that the elements that are accessed using 
> operator[] do
> exist, I would also tend to assume it should behave like a read only 
> access.

But it isn't.  Read-only accesses are things you can perform on a const
object.  You can't use operator[] on a const hash_map.  (Or on a const
map, for that matter.  You'll be unhappy if you try to think of 
operator[]
on maps as a read-only operation in a multithreaded environment.)

			--Matt